Contemporary ontologies share many structural similarities, regardless of the ontology language in which they are expressed. Most ontologies describe individuals (instances), classes (concepts), attributes, and relations. == List == Common components of ontologies include: Individuals instances or objects (the basic or "ground level" objects; the tokens). Classes sets, collections, concepts, types of objects, or kinds of things. Attributes aspects, properties, features, characteristics, or parameters that individuals (and classes and relations) can have. Relations ways in which classes and individuals can be related to one another. Relations can carry attributes that specify the relation further. Function terms complex structures formed from certain relations that can be used in place of an individual term in a statement. Restrictions formally stated descriptions of what must be true in order for some assertion to be accepted as input. Rules statements in the form of an if-then (antecedent-consequent) sentence that describe the logical inferences that can be drawn from an assertion in a particular form. Axioms assertions (including rules) in a logical form that together comprise the overall theory that the ontology describes in its domain of application. This definition differs from that of "axioms" in generative grammar and formal logic. In these disciplines, axioms include only statements asserted as a priori knowledge. As used here, "axioms" also include the theory derived from axiomatic statements. Events the changing of attributes or relations. Actions types of events. Ontologies are commonly encoded using ontology languages. == Individuals == Individuals (instances) are the basic, "ground level" components of an ontology. The individuals in an ontology may include concrete objects such as people, animals, tables, automobiles, molecules, and planets, as well as abstract individuals such as numbers and words (although there are differences of opinion as to whether numbers and words are classes or individuals). Strictly speaking, an ontology need not include any individuals, but one of the general purposes of an ontology is to provide a means of classifying individuals, even if those individuals are not explicitly part of the ontology. In formal extensional ontologies, only the utterances of words and numbers are considered individuals – the numbers and names themselves are classes. In a 4D ontology, an individual is identified by its spatio-temporal extent. Examples of formal extensional ontologies are BORO, ISO 15926 and the model in development by the IDEAS Group. == Classes == == Attributes == Objects in an ontology can be described by relating them to other things, typically aspects or parts. These related things are often called attributes, although they may be independent things. Each attribute can be a class or an individual. The kind of object and the kind of attribute determine the kind of relation between them. A relation between an object and an attribute express a fact that is specific to the object to which it is related. For example, the Ford Explorer object has attributes such as: ⟨has as name⟩ Ford Explorer ⟨as by definition as part⟩ 6-speed transmission ⟨as by definition as part⟩ door (with as minimum and maximum cardinality: 4) ⟨as by definition as part one of⟩ {4.0L engine, 4.6L engine} The value of an attribute can be a complex data type; in this example, the related engine can only be one of a list of subtypes of engines, not just a single thing. Ontologies are only true ontologies if concepts are related to other concepts (the concepts do have attributes). If that is not the case, then you would have either a taxonomy (if hyponym relationships exist between concepts) or a controlled vocabulary. These are useful, but are not considered true ontologies. == Relations == Relations (also known as relationships) between objects in an ontology specify how objects are related to other objects. Typically a relation is of a particular type (or class) that specifies in what sense the object is related to the other object in the ontology. For example, in the ontology that contains the concept Ford Explorer and the concept Ford Bronco might be related by a relation of type ⟨is defined as a successor of⟩. The full expression of that fact then becomes: Ford Explorer is defined as a successor of : Ford Bronco This tells us that the Explorer is the model that replaced the Bronco. This example also illustrates that the relation has a direction of expression. The inverse expression expresses the same fact, but with a reverse phrase in natural language. Much of the power of ontologies comes from the ability to describe relations. Together, the set of relations describes the semantics of the domain: that is, its various semantic relations, such as synonymy, hyponymy and hypernymy, coordinate relation, and others. The set of used relation types (classes of relations) and their subsumption hierarchy describe the expression power of the language in which the ontology is expressed. An important type of relation is the subsumption relation (is-a-superclass-of, the converse of is-a, is-a-subtype-of or is-a-subclass-of). This defines which objects are classified by which class. For example, we have already seen that the class Ford Explorer is-a-subclass-of 4-Wheel Drive Car, which in turn is-a-subclass-of Car. The addition of the is-a-subclass-of relationships creates a taxonomy; a tree-like structure (or, more generally, a partially ordered set) that clearly depicts how objects relate to one another. In such a structure, each object is the 'child' of a 'parent class' (Some languages restrict the is-a-subclass-of relationship to one parent for all nodes, but many do not). Another common type of relations is the mereology relation, written as part-of, that represents how objects combine to form composite objects. For example, if we extended our example ontology to include concepts like Steering Wheel, we would say that a "Steering Wheel is-by-definition-a-part-of-a Ford Explorer" since a steering wheel is always one of the components of a Ford Explorer. If we introduce meronymy relationships to our ontology, the hierarchy that emerges is no longer able to be held in a simple tree-like structure since now members can appear under more than one parent or branch. Instead this new structure that emerges is known as a directed acyclic graph. As well as the standard is-a-subclass-of and is-by-definition-a-part-of-a relations, ontologies often include additional types of relations that further refine the semantics they model. Ontologies might distinguish between different categories of relation types. For example: relation types for relations between classes relation types for relations between individuals relation types for relations between an individual and a class relation types for relations between a single object and a collection relation types for relations between collections Relation types are sometimes domain-specific and are then used to store specific kinds of facts or to answer particular types of questions. If the definitions of the relation types are included in an ontology, then the ontology defines its own ontology definition language. An example of an ontology that defines its own relation types and distinguishes between various categories of relation types is the Gellish ontology. For example, in the domain of automobiles, we might need a made-in type relationship which tells us where each car is built. So the Ford Explorer is made-in Louisville. The ontology may also know that Louisville is-located-in Kentucky and Kentucky is-classified-as-a state and is-a-part-of the U.S. Software using this ontology could now answer a question like "which cars are made in the U.S.?"
ArcObjects
ArcObjects is a development environment of the ArcGIS family of applications. Using Visual Basic for Applications, C# or Java SDK for ArcGIS, it allows developers to extend these applications.ArcObjects is a library of Component Object Model (COM) components that build up the foundation of Esri's ArcGIS platform. ArcObjects is written primarily in the C++ programming language. Since ArcGIS is completely built on top of ArcObjects, the ArcGIS platform can be fully customized and extended by making use of its COM services and capabilities. This allows for easy extension of the ArcObjects data model with any programming language that is compatible with COM, such as Visual Basic, C#, Visual Basic.NET, Java and Python. COM enables components to be reused at a binary level, meaning developers do not require access to the source code of ArcObjects in order to extend the ArcGIS platform. For this reason, an ArcObjects programmer can make use of any type inside the ArcObjects system without knowing the implementation details of the type, only needing to know what the type is able to do. The ArcObjects data model is based on the COM standard, which makes it compatible with other COM objects and applications. This allows for easy integration and collaboration with other systems that are also based on the COM standard. The ArcGIS platform was built using ArcObjects types, such as classes, interfaces, and enumerations. ArcObjects use COM interfaces to organize and communicate properties and methods of its classes, ensuring compatibility with other COM-based objects and systems. When working with an ArcObjects COM class, its properties and methods are accessed solely through one of its implemented interfaces via the process of Query Interface (QI). Multiple interfaces are commonly available for classes in ArcObjects. For example, it is possible to query for additional interfaces implemented by an object after instantiation via the process of QI. Although only one interface can be used when instantiating an object, multiple interfaces are often available for classes in ArcObjects, allowing for greater flexibility and compatibility with other systems based on the COM standard.
Svelte
Svelte is a free and open-source component-based front-end software framework and language created by Rich Harris and maintained by the Svelte core team. Svelte is not a monolithic JavaScript library imported by applications: instead, Svelte compiles HTML templates to specialized code that manipulates the DOM directly, which may reduce the size of transferred files and give better client performance. Application code is also processed by the compiler, inserting calls to automatically recompute data and re-render UI elements when the data they depend on is modified. This also avoids the overhead associated with runtime intermediate representations, such as virtual DOM, unlike traditional frameworks (such as React and Vue) which carry out the bulk of their work at runtime, i.e. in the browser. The compiler itself is written in JavaScript. Its source code is licensed under MIT License and hosted on GitHub. Among comparable frontend libraries, Svelte has one of the smallest bundle footprints at merely 2KB. == History == The predecessor of Svelte is Ractive.js, which Rich Harris created in 2013. Version 1 of Svelte was written in JavaScript and was released on 29 November 2016. The name Svelte was chosen by Rich Harris and his coworkers at The Guardian. Version 2 of Svelte was released on 19 April 2018. It set out to correct what the maintainers viewed as mistakes in the earlier version such as replacing double curly braces with single curly braces. Version 3 of Svelte was written in TypeScript and was released on 21 April 2019. It rethought reactivity by using the compiler to instrument assignments behind the scenes. The SvelteKit web framework was announced in October 2020 and entered beta in March 2021. SvelteKit 1.0 was released in December 2022 after two years in development. Version 4 of Svelte was released on 22 June 2023. It was a maintenance release, smaller and faster than version 3. A part of this release was an internal rewrite from TypeScript back to JavaScript, with JSDoc type annotations. This was met with confusion from the developer community, which was addressed by the creator of Svelte, Rich Harris. Version 5 of Svelte was released on October 19, 2024 at Svelte Summit Fall 2024 with Rich Harris cutting the release live while joined by other Svelte maintainers. Svelte 5 was a ground-up rewrite of Svelte, changing core concepts such as reactivity and reusability. Its primary feature, runes, reworked how reactive state is declared and used. Runes are function-like macros that are used to declare a reactive state, or code that uses reactive states. These runes are used by the compiler to indicate values that may change and are depended on by other states or the DOM. Svelte 5 also introduces Snippets, which are reusable "snippets" of code that are defined once and can be reused anywhere else in the component. Svelte 5 was initially met with controversy due to its many changes, and thus deprecations caused primarily by runes. However, most of this has subsided since the initial announcement of runes, and the further refining of Svelte 5. Also at Svelte Summit Fall 2024, Ben McCann announced the Svelte CLI under the sv package name on npm. In early 2025, the Svelte team announced Asynchronous Svelte, an experimental feature set centered around asynchronous reactivity in Svelte using await expressions. As of August 2025, the feature is available via an experimental compiler option. This coincided with the experimental release of remote functions, an RPC feature in SvelteKit, Svelte's metaframework. Key early contributors to Svelte became involved with Conduitry joining with the release of Svelte 1, Tan Li Hau joining in 2019, and Ben McCann joining in 2020. Rich Harris and Simon Holthausen joined Vercel to work on Svelte fulltime in 2022. Dominic Gannaway joined Vercel from the React core team to work on Svelte fulltime in 2023. == Syntax == Svelte applications and components are defined in .svelte files, which are HTML files extended with templating syntax that is based on JavaScript and is similar to JSX. Svelte's core features are accessed through runes, which syntactically look like functions, but are used as macros by the compiler. These runes include: The $state rune, used for declaring a reactive state value The $derived rune, used for declaring reactive state derived from one or more states The $effect rune, used for declaring code that reruns whenever its dependencies change Starting with Svelte 5, the framework introduced a significant reactivity overhaul that replaces the previous `$:` reactive declarations with new runes such as $state, $derived, and $effect. The $effect rune is now used for post-render operations without modifying state, while $derived is used for computations that depend on other reactive values. This change aims to simplify the mental model of reactivity and make component logic more explicit. Additionally, the { JavaScript code } syntax can be used for templating in HTML elements and components, similar to template literals in JavaScript. This syntax can also be used in element attributes for uses such as two-way data binding, event listeners, and CSS styling. A Todo List example made in Svelte is below: == Associated projects == The Svelte maintainers created SvelteKit as the official way to build projects with Svelte. It is a Next.js/Nuxt-style full-stack framework that dramatically reduces the amount of code that gets sent to the browser. The maintainers had previously created Sapper, which was the predecessor of SvelteKit. The Svelte maintainers also maintain a number of integrations for popular software projects under the Svelte organization including integrations for Vite, Rollup, Webpack, TypeScript, VS Code, Chrome Developer Tools, ESLint, and Prettier. A number of external projects such as Storybook have also created integrations with Svelte and SvelteKit. == Influence == Vue.js modeled its API and single-file components after Ractive.js, the predecessor of Svelte. == Adoption == Svelte is widely praised by developers. Taking the top ranking in multiple large scale developer surveys, it was chosen as the Stack Overflow 2021 most loved web framework and 2020 State of JS frontend framework with the most satisfied developers. Recent surveys continue to show Svelte's strong developer satisfaction, with the 2024 State of JS survey maintaining its position among the most praised frontend frameworks. The 2024 Stack Overflow Developer Survey reported that 73% of developers who used Svelte want to continue working with it, and noted that Stack Overflow's own team used Svelte for building their 2024 Developer Survey results site. Svelte has been adopted by a number of high-profile web companies including The New York Times, Google, Apple, Spotify, Radio France, Square, Yahoo, ByteDance, Rakuten, Bloomberg, Reuters, Ikea, Facebook, Logitech, and Brave. A community group of primarily non-maintainers, known as the Svelte Society, run the Svelte Summit conference, write a Svelte newsletter, host a Svelte podcast, and host a directory of Svelte tooling, components, and templates.
Mosaik Solutions
Mosaik Solutions (formerly American Roamer) was a company that specializes in wireless coverage data and wireless coverage maps, based in Memphis, Tennessee before being acquired by Ookla. The company collects and crowdsources carrier signal quality from major telecommunications providers or users who have its consumer or enterprise mobile application installed. The data is used to provide insights into places around the world without access to cellular coverage and the development of new coverage patterns, as well as to provide maps showing what provider offers the best service in an area. In 2011, the Federal Communications Commission (FCC), recognized Mosaik Solutions as the "industry standard" for the presence of wireless service at the census-block level. == History == In 2016, Mosaik purchased Sensorly, a free app developed to crowdsource cellular network performance service and provide coverage mapping for wireless networks worldwide. == Products and services == === MapELEMENTS === MapELEMENTS software is a visualization tool that allows users to analyze data from the largest cellular coverage database in the world. === CellMaps === CellMaps is an interactive mapping solution that allows companies to show their network coverage directly on their website through an iframe or API. In 2013 Mosaik launched an android app for CellMaps that provides data directly from carriers so that users can determine what carrier meets their needs in a given area. On the map you can overlay multiple carriers, zoom to street-view level, and drop a pin onto any given spot to get a breakdown of carrier service in that area. === Signal Insights App === Signal Insights is an SaaS platform service available for android users that measures and analyzes the customer's experience in cellular or Wi-Fi networks. Indoor mode allows a user to upload a building floor plan and then map and test specific points in the building for cellular or Wi-Fi connectivity. === Sensorly App === Sensorly is a free app that crowdsources cellular network performance to provide coverage mapping worldwide and mobile speed data to help consumers make informed decisions when choosing a cellular carrier. In February 2017, Sensorly launched Map Trip, a feature that allows users to map their routes and share with others their signal data at a particular point in real time. === TowerSource === TowerSource is a resource for locating cell towers and identifying ownership, availability, fiber routes, type and height. It was acquired by Mosaik Solutions in September 2014. === Network Validator === Network Validator is a SaaS solution designed for users to quickly determine whether global cellular networks exist - by country, operator and wireless technology. === CoverageRight === CoverageRight is composed of licensed GIS file datasets that identify the marketed coverage of wireless operators in the United States and worldwide. It enables users to perform spatial analyses, monitor competitive build-outs, analyze coverage trends and assemble roaming footprints. This data has been utilized by the FCC to analyze wireless coverage nationwide. === Network QoE === Network QoE is an enterprise platform that uses crowdsourced data from cellular devices to detect wireless network issues including 3G, 4G and wifi accessibility, network coverage holes and data performance issues. === Wireless Spectrum Report === In March 2017, Mosaik Solutions launched the Wireless Spectrum Report, a tabular dataset detailing facts about spectrum ownership and availability in the United States.
Fediverse
The Fediverse (commonly shortened to fedi) is a collection of social networking services that can communicate with each other (formally known as federation) using a common protocol. Users of different websites can send and receive status updates, multimedia files and other data across the network. The term Fediverse is a portmanteau of federation and universe. The majority of Fediverse platforms are based on free and open-source software, and create connections between servers using the ActivityPub protocol. Some software still supports older federation protocols as well, such as OStatus, the Diaspora protocol and Zot, while newer protocols such as AT Protocol connect via network bridges. Diaspora is the only actively developed software project classified under the original definition of Fediverse that does not support ActivityPub. == Design == While a traditional social networking service will host all its content on servers managed by the owner of the website, the decentralized structure of the Fediverse allows any individual or organization to host a social platform using their own servers (referred to as an "instance"). Every instance is independent, and can set its own rules and expectations. Even so, much like how users of one email service such as Gmail can still send emails to users of another service such as Outlook, users may still view content and interact with users on any other instance in the Fediverse. A user on one Mastodon instance, for example, may view and interact with posts made by a user on a different instance even if it is not running Mastodon. Instances hosted by different social networking services may also communicate with one another. A user on the microblogging platform Misskey, for example, may view and interact with posts made by users on Mastodon. Some Fediverse networks even allow users to interact with different social networking formats from the same platform. For example, a user on a social news instance running Lemmy can interact with another post from an mbin instance, a similar service, as well as microblog statuses from Mastodon. === Content moderation and user safety === Decentralized social networking platforms introduce new challenges and difficulties for user trust and safety. By nature of the Fediverse, operators of an instance are solely responsible for moderation of its content. As there is no form of centralized governance or moderation across the Fediverse, it is impossible for an instance to be "removed" from the Fediverse; it can only be defederated per an instance operator's choice, which makes that instance's content inaccessible from the operator's instance. Individual instances are responsible for defining their own content policies, which may then be enforced by its staff. Moderation of a Fediverse instance differs significantly from that of traditional social media platforms, as moderators are responsible not only for content posted by users of that instance ("local users"), but also for content posted by users of other instances ("remote users"). == History == === Historical protocols === The concept and the functionality of the Fediverse existed before the ActivityPub protocol and the term itself. One of the first projects that included support for a decentralized social networking service was Laconica, a microblogging platform which implemented the OpenMicroBlogging protocol for communicating between different installations of the software. The software was later renamed to StatusNet in 2009, before being merged into the GNU social project in 2013 along with Free Social, with the two latter servers being a fork of StatusNet. Over time, the limitations of the OpenMicroBlogging protocol became more apparent, being designed as a one-way text messaging system. To replace the ageing protocol, OStatus was devised as an open standard for microblogging, combining various other technologies like Salmon, Atom, WebSub and ActivityStreams into a single protocol used for communicating between instances. StatusNet first implemented the OStatus protocol on March 3, 2010, with version 0.9.0, and OStatus quickly became the most popular federated protocol in usage. Around the same time as OStatus was gaining popularity, the Diaspora social network was formed, using its own federated protocol. To illustrate the differences between the two protocols, the terms of the Fediverse and the federation began to enter common usage, mainly after 2017. The term "the Fediverse" was used to describe the network formed by software using the OStatus protocol, such as GNU Social, Mastodon, and Friendica, in contrast to the competing diaspora protocol under "the federation". === ActivityPub === In December 2012, the flagship StatusNet instance at the time, identi.ca, transitioned away to a new software named pump.io, with a new federation protocol to replace OStatus. The new protocol was designed to be useful for general activity streams and not just status updates, and replaced many of OStatus' external dependencies with JSON-LD and a REST API for its messaging and inbox systems, as well as making more use of ActivityStreams. While not as utilized as its OStatus predecessor, it would later become influential in the development of the ActivityPub standard. In January 2018, the W3C presented the ActivityPub protocol as a recommended standard. The standard aimed to improve the interoperability between different software packages running on a wide network of servers and to supersede both the OStatus protocol and Pump.io. By 2019, almost all software that was using OStatus had added support for ActivityPub. While Mastodon began to remove OStatus support, other projects maintained it in their code, such as Friendica (which also maintained diaspora support along with ActivityPub). === AT Protocol === A major protocol often contrasted with ActivityPub is the AT Protocol, which powers the Bluesky social network. While both protocols aim to create decentralized social networks, they employ different technical philosophies regarding user identity. Developers of the AT Protocol, including Bluesky CEO Jay Graber, have stated they chose not to use ActivityPub because it did not natively support easy "account portability", the ability for a user to move their account, data, and social graph to a new provider without relying on the original server to authorize the move. In the ActivityPub model (used by Mastodon), a user's identity is typically tied to a specific server, similar to an email address; if that server goes offline, the identity can be lost. The AT Protocol aims to solve this by separating identity from hosting, allowing users to switch providers without losing their identity. Although the two protocols are technically incompatible by default, third-party "bridges" such as Bridgy Fed have been developed to allow users on ActivityPub networks to follow and interact with users on the AT Protocol network, and vice versa. === Other Fediverse protocols === While the Fediverse has traditionally been the network most commonly referred to and used as an example regarding the subject of decentralized social networks, alternatives to it and the accompanying ActivityPub have been developed and deployed. Smaller competitors such as Nostr and Farcaster have become popular within the cryptocurrency community. These protocols have used ActivityPub as a frame of reference for which to design their own architecture, as these newer protocols use a different federation model based on publishing content to relays for distribution rather than ActivityPub's server-centric model. Despite their differences, software exists that permit the bridging of user content between these protocols, including "double-bridges" that span multiple protocols for the purpose of distributing the same content. == Adoption == Users have been slow to embrace the Fediverse due to poor user experience and excessive complexity. Following the acquisition of Twitter by Elon Musk in November 2022, certain major social networks, including Threads, Tumblr and Flipboard, expressed interest in supporting the ActivityPub protocol, as a large number of users began to migrate to Mastodon, a server that supports the Fediverse and was also the most popular alternative to Twitter at the time. Flickr also expressed support in supporting ActivityPub. As of November 2022, no information had been released by Flickr after the initial tweets by the CEO, with support for ActivityPub suspected to be on hold or cancelled. In 2024, the local government of the Stary Sącz municipality in Poland launched their own PeerTube instance in order to de facto abolish its presence on YouTube. According to the government, they stopped using YouTube for official communications "in order to adhere to the appropriate regulations". In the same year, VIVERSE, HTC Vive's metaverse platform, implemented support for ActivityPub in their chat feature, allowing users to send direct messages to other
Event condition action
Event condition action (ECA) is a short-cut for referring to the structure of active rules in event-driven architecture and active database systems. Such a rule traditionally consisted of three parts: The event part specifies the signal that triggers the invocation of the rule The condition part is a logical test that, if satisfied or evaluates to true, causes the action to be carried out The action part consists of updates or invocations on the local data This structure was used by the early research in active databases which started to use the term ECA. Current state of the art ECA rule engines use many variations on rule structure. Also other features not considered by the early research is introduced, such as strategies for event selection into the event part. In a memory-based rule engine, the condition could be some tests on local data and actions could be updates to object attributes. In a database system, the condition could simply be a query to the database, with the result set (if not null) being passed to the action part for changes to the database. In either case, actions could also be calls to external programs or remote procedures. Note that for database usage, updates to the database are regarded as internal events. As a consequence, the execution of the action part of an active rule can match the event part of the same or another active rule, thus triggering it. The equivalent in a memory-based rule engine would be to invoke an external method that caused an external event to trigger another ECA rule. ECA rules can also be used in rule engines that use variants of the Rete algorithm for rule processing. == ECA rule engines == Rulecore Concurrent Rules Apart Database Detect Invocation Rules ConceptBase ECArules
Solid-state electronics
Solid-state electronics are semiconductor electronics: electronic equipment that use semiconductor devices such as transistors, diodes and integrated circuits (ICs). The term is also used as an adjective for devices in which semiconductor electronics that have no moving parts replace devices with moving parts, such as the solid-state relay, in which transistor switches are used in place of a moving-arm electromechanical relay, or the solid-state drive (SSD), a type of semiconductor memory used in computers to replace hard disk drives, which store data on rotating disks. == History == The term solid-state became popular at the beginning of the semiconductor era in the 1960s to distinguish this new technology. A semiconductor device works by controlling an electric current consisting of electrons or holes moving within a solid crystalline piece of semiconducting material such as silicon, while the thermionic vacuum tubes it replaced worked by controlling a current of electrons or ions in a vacuum within a sealed tube. Although the first solid-state electronic device was the cat's whisker detector, a crude semiconductor diode invented around 1904, solid-state electronics started with the invention of the transistor in 1947. Before that, all electronic equipment used vacuum tubes, because vacuum tubes were the only electronic components that could amplify—an essential capability in all electronics. The transistor, which was invented by John Bardeen and Walter Houser Brattain while working under William Shockley at Bell Laboratories in 1947, could also amplify, and replaced vacuum tubes. The first transistor hi-fi system was developed by engineers at GE and demonstrated at the University of Philadelphia in 1955. In terms of commercial production, The Fisher TR-1 was the first "all transistor" preamplifier, which became available mid-1956. In 1961, a company named Transis-tronics released a solid-state amplifier, the TEC S-15. The replacement of bulky, fragile, energy-hungry vacuum tubes by transistors in the 1960s and 1970s created a revolution not just in technology but in people's habits, making possible the first truly portable consumer electronics such as the transistor radio, cassette tape player, walkie-talkie and quartz watch, as well as the first practical computers and mobile phones. Other examples of solid state electronic devices are the microprocessor chip, LED lamp, solar cell, charge coupled device (CCD) image sensor used in cameras, and semiconductor laser. Also during the 1960s and 1970s, television set manufacturers switched from vacuum tubes to semiconductors, and advertised sets as "100% solid state" even though the cathode-ray tube (CRT) was still a vacuum tube. It meant only the chassis was 100% solid-state, not including the CRT. Early advertisements spelled out this distinction, but later advertisements assumed the audience had already been educated about it and shortened it to just "100% solid state". LED displays can be said to be truly 100% solid-state.