A document-oriented database, or document store, is a computer program and data storage system designed for storing, retrieving, and managing document-oriented information, also known as semi-structured data. Document-oriented databases are one of the main categories of NoSQL databases, and the popularity of the term "document-oriented database" has grown alongside the adoption of NoSQL itself. XML databases are a subclass of document-oriented databases optimized for XML documents. Graph databases are similar, but add another layer, the relationship, which allows them to link documents for rapid traversal. Document-oriented databases are conceptually an extension of the key–value store, another type of NoSQL database. In key-value stores, data is treated as opaque by the database, whereas document-oriented systems exploit the internal structure of documents to extract metadata and optimize storage and queries. Although in practice the distinction can be minimal due to modern tooling, document stores are designed to provide a richer programming experience with modern programming techniques. Document databases differ significantly from traditional relational databases (RDBs). Relational databases store data in predefined tables, often requiring an object to be split across multiple tables. In contrast, document databases store all information for a given object in a single document, with each document potentially having a unique structure. This design eliminates the need for object-relational mapping when loading data into the database. == Documents == The central concept of a document-oriented database is the notion of a document. Although implementations vary in their specific definitions, document-oriented databases generally treat documents as self-contained units that encapsulate and encode data in a standardized format. Common encoding formats include XML, YAML, JSON, as well as binary representations such as BSON. Documents in a document store are equivalent to the programming concept of an object. They are not required to adhere to a fixed schema, and documents within the same collection may contain different fields or structures. Fields may be optional, and documents of the same logical type may differ in composition. For example, the following illustrates a document encoded in JSON: A second document might be encoded in XML as: The two example documents share some structural elements but also contain unique fields. The structure, text, and other data within each document are collectively referred to as the document's content and can be accessed or modified using retrieval or editing operations. Unlike relational databases, in which each record contains the same fields and unused fields are left empty, document-oriented databases do not require uniform fields across documents. This design allows new information to be added to some documents without affecting the structure of others. Document databases often support the storage of additional metadata alongside the document content. Such metadata may relate to organizational features, security, indexing, or other implementation-specific features. === CRUD operations === The core operations supported by a document-oriented database for manipulating documents are similar to those in other databases. Although terminology is not perfectly standardized, these operations are generally recognized as Create, Read, Update, and Delete (CRUD). Creation (C): Adds a new document to the database. Retrieval (R): Retrieves documents or fields based on queries. Update (U): Modifies the contents of existing documents. Deletion (D): Removes documents from the database. === Keys === Documents in a document-oriented database are addressed via a unique identifier. This identifier, often a string, URI, or path, can be used to retrieve the document from the database. Most document stores maintain an index on the key to optimize retrieval, and in some implementations the key is required when creating or inserting a new document. === Retrieval === In addition to key-based access, document-oriented databases typically provide an API or query language that enables retrieval based on document content or associated metadata. For example, a query may return all documents with a specific field matching a given value. The available query features, indexing options, and performance characteristics vary across implementations. Document stores differ from key-value stores in that they exploit the internal structure and metadata of stored documents. In many key-value stores, values are treated as opaque or "black-box" data, meaning the database system does not interpret their internal structure. By contrast, document-oriented databases can classify and interpret document content. This enables queries that distinguish between types of data––for example, retrieving all phone numbers containing "555" without also matching a postal code such as "55555." === Editing === Document databases typically provide mechanisms for updating or editing the content or metadata of a document. Updates may involve replacing the entire document or modifying individual elements or fields within the document. === Organization === Document database implementations support a variety of methods for organizing documents, including: Collections: Groups of documents. Depending on the implementation, a document may be required to belong to a single collection or may be allowed in multiple collections. Tags and non-visible metadata: Additional data stored outside the main document content. Directory hierarchies: Documents organized in a tree-like structure, often based on path or URI. These organizational structures may differ between logical and physical representations (e.g. on disk or in memory). == Relationship to other databases == === Relationship to key-value stores === A document-oriented database can be viewed as a specialized form of key-value store, which is itself a category of NoSQL database. In a basic key-value store, the stored value is typically treated as opaque by the database system. By contrast, a document-oriented database provides APIs or a query and update language that allows queries and modifications based on the internal structure of the document. For users who do not require advanced query, retrieval, or update capabilities, the distinction between document-oriented databases and key-value stores may be minimal. === Relationship to search engines === Some search engine and information retrieval systems, such as Apache Solr and Elasticsearch, provide document storage and support core document operations. As a result, they may meet certain functional definitions of a document-oriented database, although their primary design goals differ. === Relationship to relational databases === In a relational database, data is organized into predefined types represented as tables. Each table contains rows (records) with a fixed set of columns (fields), so all records in a table share the same structure. Administrators typically define indexes on selected fields to improve query performance. A central principle of relational database design is database normalization, in which data that might otherwise be repeated is stored in separate tables and linked using keys. When records in different tables are related, a foreign key is used to associate them. For example, an address book application may store a contact's name, image, phone numbers, mailing addresses, and email addresses. In a normalized relational design, separate tables might be created for contacts, phone numbers, and email addresses. The phone number table would include a foreign key referencing the associated contact. To reconstruct a complete contact record, the database retrieves related information from each table using the foreign keys and combines it into a single record. In contrast, a document-oriented database stores all data related to an object within a single document, and stored in the database as a single entry. In the address book example,the contact's name, image, and contact information may be stored together in one document. The document is retrieved using a unique key, and all related information is returned together, without needing to look up multiple tables. A key difference between the document-oriented and relational models is that the data formats are not predefined in the document case. In most cases, any sort of document can be stored in a database, and documents can change in type and form over time. For example, a new field such as COUNTRY_FLAG can be added to new documents as they are inserted without affecting existing documents. To aid retrieval, document-oriented systems generally allow the administrator to provide hints to the database for locating certain types of information. These hints work in a similar fashion to indexes in relational databases. Many systems also allow additional metadata outside the content of the document itself
LemonStand
LemonStand was a Canadian e-commerce company headquartered in Vancouver, British Columbia, that developed cloud-based computer software for online retailers. LemonStand was shut down on June 5, 2019. == History == LemonStand Version 1 was launched on July 28, 2001. It is written in the PHP programming language. Version 1 was released as an on-premises proprietary licensed software, and the commercial license was not free. However, there was a free trial license available. June 2012, LemonStand raised seed funding from the BDC Venture Capital, and a group of angel investors. December 20, 2013, a cloud-based SaaS version of the LemonStand eCommerce platform was released publicly. May 9, 2014, LemonStand and Payfirma, a payments processing company, partnered to provide integrated services for online retailers. May 3, 2016, LemonStand raised funding from BDC Venture Capital and Silicon Valley–based angel investors. March 5, 2019, LemonStand announced their intention to shut down on June 5, 2019. LemonStand was quietly acquired by Mailchimp at the end of February. == Pricing == LemonStand offered three levels of service plans. LemonStand did not charge any transaction fees.
OpenVINO
OpenVINO is an open-source software toolkit developed by Intel for optimizing and deploying deep learning models. It supports several popular model formats and categories, such as large language models, computer vision, and generative AI. OpenVINO is optimized for Intel hardware, but offers support for ARM/ARM64 processors. It sees great use in AI Sound Processing drivers when tied with Intel's Gaussian & Neural Accelerator (GNA). Based in C++, it extends API support for C and Python, as well as Node.js (in early preview). OpenVINO is cross-platform and free for use under Apache License 2.0. == Workflow == The simplest OpenVINO usage involves obtaining a model and running it as is. Yet for the best results, a more complete workflow is suggested: obtain a model in one of supported frameworks, convert the model to OpenVINO IR using the OpenVINO Converter tool, optimize the model, using training-time or post-training options provided by OpenVINO's NNCF. execute inference, using OpenVINO Runtime by specifying one of several inference modes. == OpenVINO model format == OpenVINO IR is the default format used to run inference. It is saved as a set of two files, .bin and .xml, containing weights and topology, respectively. It is obtained by converting a model from one of the supported frameworks, using the application's API or a dedicated converter. Models of the supported formats may also be used for inference directly, without prior conversion to OpenVINO IR. Such an approach is more convenient but offers fewer optimization options and lower performance, since the conversion is performed automatically before inference. Some pre-converted models can be found in the Hugging Face repository. The supported model formats are: PyTorch TensorFlow TensorFlow Lite ONNX (including formats that may be serialized to ONNX) PaddlePaddle JAX/Flax == OS support == OpenVINO runs on Windows, Linux and MacOS.
LG ThinQ
LG ThinQ (pronounced as "think-cue"; sometimes known as LG webOS) is a smart home and artificial intelligence brand launched by LG Electronics in 2017, featuring products that are equipped with voice control and artificial intelligence technology. The brand was originally launched for home appliances and consumer electronics, such as televisions, smart home devices, mobile devices, refrigerators, air conditioners and related services. The name was first used in 2011 for LG's THINQ-branded smart appliances, which were introduced at the Consumer Electronics Show in Las Vegas. In December 2017, LG announced ThinQ as a unified brand for artificial intelligence-enabled home appliances, consumer electronics and services.In February 2018, LG announced the LG V30S ThinQ, which is the first phone to have the "ThinQ" branding. == History == The branding was first introduced in 2011 in the Consumer Electronics Show (CES) in Las Vegas as THINQ. The first ThinQ product was a smart refrigerator, with features such as smart savings options, food management system, washing machine, oven and robotic vacuum cleaner and different software in the LCD screen on the fridge. The unified branding was then officially launched as ThinQ at CES 2017 as an artificial intelligence-based brand for all their smart products. The company announced DeepThinQ, a deep-learning technology for connected products, and later opened an Artificial Intelligence Lab in Seoul to coordinate research involving voice, video, sensors and machine learning. In December 2017, LG announced ThinQ as a brand designation for home appliances, consumer electronics, and services incorporating artificial intelligence, applied to its 2018 product lineup. In 2018, LG extended the ThinQ brand to smartphones with the LG V30S ThinQ. The phone used ThinQ branding for AI camera features, including image recognition and shooting-mode recommendations. That year, LG also used ThinQ branding on televisions with smart-assistant features, as manufacturers increasingly added voice assistants to TV platforms. In 2022, LG first introduced ThinQ UP, a software-upgradable appliance concept that allows compatible appliances to receive new features through the ThinQ app. The program included appliances such as refrigerators, washing machines, dryers, ovens and dishwashers, and was covered as part of a wider move toward upgradeable connected appliances. In 2024, LG introduced ThinQ ON, an AI-powered smart home hub designed to connect LG appliances and other smart home devices. It expanded ThinQ from an appliance-control platform into a broader smart home system. == Platform an app == LG ThinQ operates as a smart home platform and mobile app for connecting compatible LG appliances and consumer electronics. The app is used to control and monitor supported products, including kitchen appliances, laundry appliances, air purifiers, vacuum cleaners and televisions. Depending on the product and market, the ThinQ app can provide remote control, status monitoring, downloadable appliance cycles, diagnostic support, maintenance alerts and software-based feature updates. In 2024, LG introduced ThinQ ON as a hub for the ThinQ platform. The device supports Matter, Thread and Wi-Fi connectivity and includes a built-in voice assistant. The Verge described the product as part of LG's effort to expand ThinQ from an appliance-control platform into a broader smart home system competing with platforms such as Samsung SmartThings and Apple Home. == Features == LG ThinQ products use connected-device features, voice control to interact with users, and use sensor data and different features such as product recognition and learning engine technologies to enhance their abilities. Deep ThinQ (or LG ThinQ AI) was introduced as LG's own AI platform. It was reported that it could engage in two-way conversations with users and could educate itself according to users' behaviour patterns and habits. At the 2017 ThinQ launch, LG said the brand would cover products and services using artificial intelligence technologies from LG and partner companies. ThinQ features vary by product category. On appliances, the platform may support remote operation, product-status notifications, downloaded cycles and diagnostic functions. On televisions, ThinQ branding has been associated with voice-control and smart-assistant features. In 2018, LG ThinQ-branded TVs added support for Google Assistant and Alexa voice commands. As of August 30, 2018, LG's ThinQ products now communicate with each other for tasks such as going to an event or following a recipe. They have sensors for communicating with other ThinQ devices and appliances. == Products == LG ThinQ branding and connectivity features have been used across several LG product categories, including home appliances, televisions, air conditioners and mobile devices. Home appliances LG has applied ThinQ branding and app connectivity to home appliances such as refrigerators, washing machines, dryers, dishwashers, cooking appliances, air purifiers and vacuum cleaners. Through the ThinQ app, compatible appliances can be monitored or controlled remotely. Some compatible appliances can also receive downloadable cycles, diagnostic support, maintenance alerts and software-based feature updates through ThinQ UP. Televisions and home entertainment LG has used ThinQ branding on smart televisions and other home entertainment products. In 2018, LG ThinQ-branded televisions added support for smart-assistant voice commands, including Google Assistant. Smartphones LG G6 (ThinQ branding was added to startup screen in an update) LG V30 (ThinQ branding was added to startup screen in an update) LG V30S ThinQ LG V35 ThinQ LG G7 ThinQ LG V40 ThinQ LG G8 ThinQ LG G8s ThinQ LG G8x ThinQ LG V50 ThinQ LG V60 ThinQ LG Velvet (Generally considered a ThinQ product in other countries)
Semantic parameterization
Semantic parameterization is a conceptual modeling process for expressing natural language descriptions of a domain in first-order predicate logic. The process yields a formalization of natural language sentences in Description Logic to answer the who, what and where questions in the Inquiry-Cycle Model (ICM) developed by Colin Potts and his colleagues at the Georgia Institute of Technology. The parameterization process complements the Knowledge Acquisition and autOmated Specification (KAOS) method, which formalizes answers to the when, why and how ICM questions in Temporal Logic, to complete the ICM formalization. The artifacts used in the parameterization process include a dictionary that aligns the domain lexicon with unique concepts, distinguishing between synonyms and polysemes, and several natural language patterns that aid in mapping common domain descriptions to formal specifications. == Relationship to other theories == Semantic Parameterization defines a meta-model consisting of eight roles that are domain-independent and reusable. Seven of these roles correspond to Jeffrey Gruber's thematic relations and case roles in Charles Fillmore's case grammar: The Inquiry-Cycle Model (ICM) was introduced to drive elicitation between engineers and stakeholders in requirements engineering. The ICM consists of who, what, where, why, how and when questions. All but the when questions, which require a Temporal Logic to represent such phenomena, have been aligned with the meta-model in semantic parameterization using Description Logic (DL). == Introduction with Example == The semantic parameterization process is based on Description Logic, wherein the TBox is composed of words in a dictionary, including nouns, verbs, and adjectives, and the ABox is partitioned into two sets of assertions: 1) those assertions that come from words in the natural language statement, called the grounding, and 2) those assertions that are inferred by the (human) modeler, called the meta-model. Consider the following unstructured natural language statement (UNLS) (see Breaux et al. for an extended discussion): UNLS1.0 The customer1,1 must not share2,2 the access-code3,3 of the customer1,1 with someone4,4 who is not the provider5,4. The modeler first identifies intensional and extensional polysemes and synonyms, denoted by the subscripts: the first subscript uniquely refers to the intensional index, i.e., the same first index in two or more words refer to the same concept in the TBox; the second subscript uniquely refers to the extensional index, i.e., two same second index in two or more words refer to the same individual in the ABox. This indexing step aligns words in the statement and concepts in the dictionary. Next, the modeler identifies concepts from the dictionary to compose the meta-model. The following table illustrates the complete DL expression that results from applying semantic parameterization.
Vanish (computer science)
Vanish was a project to "give users control over the lifetime of personal data stored on the web." It was led by Roxana Geambasu at the University of Washington. The project proposed to allow a user to enter information to send across the internet, thereby relinquishing control of it. However, the user can include an "expiration date," after which the information is no longer usable by anyone who may have a copy of it, even the creator. The Vanish approach was found to be vulnerable to a Sybil attack and thus insecure by a team called Unvanish from the University of Texas, University of Michigan, and Princeton. == Theory == Vanish acts by automating the encryption of information entered by the user with an encryption key that is unknown to the user. Along with the information the user enters, the user also enters metadata concerning how long the information should remain available. The system then encrypts the information but does not store either the encryption key or the original information. Instead, it breaks up the decryption key into smaller components that are disseminated across distributed hash tables, or DHTs, via the Internet. The DHTs refresh information within their nodes on a set schedule unless configured to make the information persistent. The time delay entered by the user in the metadata controls how long the DHTs should allow the information to persist, but once that time period is over, the DHTs will reuse those nodes, making the information about the decryption stored irretrievable. As long as the decryption key may be reassembled from the DHTs, the information is retrievable. However, once the period entered by the user has lapsed, the information is no longer recoverable, as the user never possessed the decryption key. == Implementation == Vanish currently exists as a Firefox plug-in which allows a user to enter text into either a standard Gmail email or Facebook message and choose to send the message via Vanish. The message is then encrypted and sent via the normal networking pathways through the cloud to the recipient. The recipient must have the same Firefox plug-in to decrypt the message. The plugin accesses BitTorrent DHTs, which have 8-hour lifespans. This means the user may select an expiration date for the message in increments of 8 hours. After the expiration of the user-defined time span, the information in the DHT is overwritten, thereby eliminating the key. While both the user and recipient may have copies of the original encrypted message, the key used to turn it back into plain text is now gone. Although this particular instance of the data has become inaccessible, it's important to note that the information can always be saved by other means before expiration (copied or even via screen shots) and published again.
Yale shooting problem
The Yale shooting problem is a conundrum or scenario in formal situational logic on which early logical solutions to the frame problem fail. The name of this problem comes from a scenario proposed by its inventors, Steve Hanks and Drew McDermott, working at Yale University when they proposed it. In this scenario, Fred (later identified as a turkey) is initially alive and a gun is initially unloaded. Loading the gun, waiting for a moment, and then shooting the gun at Fred is expected to kill Fred. However, if inertia is formalized in logic by minimizing the changes in this situation, then it cannot be uniquely proved that Fred is dead after loading, waiting, and shooting. In one solution, Fred indeed dies; in another (also logically correct) solution, the gun becomes mysteriously unloaded and Fred survives. Technically, this scenario is described by two fluents (a fluent is a condition that can change truth value over time): a l i v e {\displaystyle alive} and l o a d e d {\displaystyle loaded} . Initially, the first condition is true and the second is false. Then, the gun is loaded, some time passes, and the gun is fired. Such problems can be formalized in logic by considering four time points 0 {\displaystyle 0} , 1 {\displaystyle 1} , 2 {\displaystyle 2} , and 3 {\displaystyle 3} , and turning every fluent such as a l i v e {\displaystyle alive} into a predicate a l i v e ( t ) {\displaystyle alive(t)} depending on time. A direct formalization of the statement of the Yale shooting problem in logic is the following one: a l i v e ( 0 ) {\displaystyle alive(0)} ¬ l o a d e d ( 0 ) {\displaystyle \neg loaded(0)} t r u e → l o a d e d ( 1 ) {\displaystyle true\rightarrow loaded(1)} l o a d e d ( 2 ) → ¬ a l i v e ( 3 ) {\displaystyle loaded(2)\rightarrow \neg alive(3)} The first two formulae represent the initial state. The third formula formalizes the effect of loading the gun at time 1 {\displaystyle 1} . The fourth formula formalizes the effect of shooting at Fred at time 2 {\displaystyle 2} . This is a simplified formalization in which action names are neglected and the effects of actions are directly specified for the time points in which the actions are executed. See situation calculus for details. The formulae above, while being direct formalizations of the known facts, do not suffice to correctly characterize the domain. Indeed, ¬ a l i v e ( 1 ) {\displaystyle \neg alive(1)} is consistent with all these formulae, although there is no reason to believe that Fred dies before the gun has been shot. The problem is that the formulae above only include the effects of actions, but do not specify that all fluents not changed by the actions remain the same. In other words, a formula a l i v e ( 0 ) ≡ a l i v e ( 1 ) {\displaystyle alive(0)\equiv alive(1)} must be added to formalize the implicit assumption that loading the gun only changes the value of l o a d e d {\displaystyle loaded} and not the value of a l i v e {\displaystyle alive} . The necessity of a large number of formulae stating the obvious fact that conditions do not change unless an action changes them is known as the frame problem. An early solution to the frame problem was based on minimizing the changes. In other words, the scenario is formalized by the formulae above (that specify only the effects of actions) and by the assumption that the changes in the fluents over time are as minimal as possible. The rationale is that the formulae above enforce all effect of actions to take place, while minimization should restrict the changes to exactly those due to the actions. In the Yale shooting scenario, one possible evaluation of the fluents in which the changes are minimized is the following one. This is the expected solution. It contains two fluent changes: l o a d e d {\displaystyle loaded} becomes true at time 1 and a l i v e {\displaystyle alive} becomes false at time 3. The following evaluation also satisfies all formulae above. In this evaluation, there are still two changes only: l o a d e d {\displaystyle loaded} becomes true at time 1 and false at time 2. As a result, this evaluation is considered a valid description of the evolution of the state, although there is no valid reason to explain l o a d e d {\displaystyle loaded} being false at time 2. The fact that minimization of changes leads to wrong solution is the motivation for the introduction of the Yale shooting problem. While the Yale shooting problem has been considered a severe obstacle to the use of logic for formalizing dynamical scenarios, solutions to it have been known since the late 1980s. One solution involves the use of predicate completion in the specification of actions: in this solution, the fact that shooting causes Fred to die is formalized by the preconditions: alive and loaded, and the effect is that alive changes value (since alive was true before, this corresponds to alive becoming false). By turning this implication into an if and only if statement, the effects of shooting are correctly formalized. (Predicate completion is more complicated when there is more than one implication involved.) A solution proposed by Erik Sandewall was to include a new condition of occlusion, which formalizes the “permission to change” for a fluent. The effect of an action that might change a fluent is therefore that the fluent has the new value, and that the occlusion is made (temporarily) true. What is minimized is not the set of changes, but the set of occlusions being true. Another constraint specifying that no fluent changes unless occlusion is true completes this solution. The Yale shooting scenario is also correctly formalized by the Reiter version of the situation calculus, the fluent calculus, and the action description languages. In 2005, the 1985 paper in which the Yale shooting scenario was first described received the AAAI Classic Paper award. In spite of being a solved problem, that example is still sometimes mentioned in recent research papers, where it is used as an illustrative example (e.g., for explaining the syntax of a new logic for reasoning about actions), rather than being presented as a problem.