A content reference identifier or CRID is a concept from the standardization work done by the TV-Anytime forum. It is or closely matches the concept of the Uniform Resource Locator, or URL, as used on the World-Wide Web: A unit of content, in a broadcast stream, can be referred to by its globally unique CRID in the same way that a webpage can be referred to by its globally unique URL on the web. The concept of CRID permits referencing contents unambiguously, regardless of their location, i.e., without knowing specific broadcast information (time, date and channel) or how to obtain them through a network, for instance, by means of a streaming service or by downloading a file from an Internet server. The receiver must be capable of resolving these unambiguous references, i.e. of translating them into specific data that will allow it to obtain the location of that content in order to acquire it. This makes it possible for recording processes to take place without knowing that information, and even without knowing beforehand the duration of the content to be recorded: a complete series by a simple click, a program that has not been scheduled yet, a set of programs grouped by a specific criterion... This framework allows for the separation between the reference to a given content (the CRID) and the necessary information to acquire it, which is called a “locator”. Each CRID may lead to one or more locators which will represent different copies of the same content. They may be identical copies broadcast in different channels or dates, or cost different prices. They may also be distinct copies with different technical parameters such as format or quality. It may also be the case that the resolution process of a CRID provides another CRID as a result (for example, its reference in a different network, where it has an alternative identifier assigned by a different operator) or a set of CRIDs (for instance, if the original CRID represents a TV series, in which case the resolution process would result in the list of CRIDs representing each episode). From the above it can be concluded that provided that a given content can belong to many groups (each possibly defined by distinctive qualities), it is possible that many CRIDs carry the same content. That is, several CRIDs may be resolved into the same locator. A CRID is not exactly a universal, unique and exclusive identifier for a given content. It is closely related to the authority that creates it, to the resolution service provider, and to the content provider in such a way that the same content may have different CRIDs depending on the field in which they are used (for example, a different one for each television operator that has the rights to broadcast the content). == Format == A CRID is specified much like URLs. In fact, a CRID is a so-called URI. Typically, the content creator, the broadcaster or a third party will use their DNS-names in a combination with a product-specific name to create globally unique CRIDs. That is, the syntax of a CRID is: crid://authority/data The authority field represents the entity that created the CRID and its format is that of a DNS name. The data field represents a string of characters that will unambiguously identify the content within the authority scope (it is a string of characters assigned by the authority itself). As an example, let's assume that BBC wanted to make a CRID for (all the programs of) the Olympics in China. It may have looked something like this crid://bbc.co.uk/olympics/2008/ This would be a group CRID, that is, a CRID representing a group of contents. Then, to refer to a specific event – such as the women's shot-put final – they could have used the following inside their metadata. crid://bbc.co.uk/olympics/2008/final/shotput/women Currently, four types of CRIDs are playing a major role in some unidirectional television networks: programme CRID, series CRID, group CRID, and recommendation CRID. One of the most important applications of CRIDs is the so-called series link recording function (SL) of modern digital video recorders (DVR, PVR). In turn, a locator is a string of characters that contains all the necessary information for a receiver to find and acquire a given content, whether it is received through a transport stream, located in local storage, downloaded as a file from an Internet server, or through a streaming service. For example, a DVB locator will include all the necessary parameters to identify a specific content within a transport stream: network, transport stream, service, table and/or event identifiers. The locators' format, as established in TV-Anytime, is quite generic and simple, and corresponds to: [transport-mechanism]:[specific-data] The first part of the locator's format (the transport mechanism) must be a string of characters that is unique for each mechanism (transport stream, local file, HTTP Internet access...). The second part must be unambiguous only within the scope of a given transport mechanism and will be standardized by the organism in charge of the regulation of the mechanism itself. For instance, a DVB locator to identify a content within the transport stream of networks that follow this standard would be: dvb://112.4a2.5ec;2d22~20121212T220000Z—PT01H30M which would indicate a content (identified by the string “2d22”) that airs on a channel available on a DVB network identified by the address “112.4a2.5ec” (network “112”, transport stream “4a2” and service “5ec”), on 12 December 2012 at 10 p.m. and with a duration of 90 minutes. == The location resolution process == The location resolution process is the procedure by which, starting from the CRID of a given content, one or several locators of that content are obtained. Resolving a CRID can be a direct process, which leads immediately to one or many locators, or it may also happen that in the first place one or many intermediate CRIDs are returned, which must undergo the same procedure to finally obtain one or several locators. This procedure involves some information elements, among which we find two structures named resolving authority record (RAR) and ContentReferencingTable, respectively. Consulting them repeatedly will take the receiver from a CRID to one or many locators that will allow it to acquire the content. The RAR table The RAR table is one or many data structures that provide the receiver, for each authority that submits CRIDs, information on the corresponding resolution service provider. Among other things, it informs about which mechanism is used to provide information to resolve the CRIDs from each authority. That is, one or many RAR records must exist for each authority that indicate the receiver where it has to go to resolve the CRIDs of that particular authority. For example, in the record of the figure (expressed by means of a XML structure, according to the XML Schema defined in the TV-Anytime) there is an authority called “tve.es”, whose resolution service provider is the entity “rtve.es”, available on the URL "http://tva.rtve.es/locres/tve", which means there is resolution information in that URL. These RAR records will have reached the receiver in an indefinite form, unimportant for the TV-Anytime specification, which will depend on the specific transport mechanism of the network to which the receiver is connected. Each family of standards that regulates distribution networks (DVB, ATSC, ISDB, IPTV...) will have previously defined such procedure, which will be used by devices certified according to those standards. The ContentReferencingTable table The second structure involved in the location resolution process is a proper resolution table which, given a content's CRID, returns one or several locators that enable the receiver to access an instance of that content, or one or many CRIDs that allow it to move forward in the resolution process. The figure shows an example of this second structure, an XML document according to the specifications of the XML Schema defined in TV-Anytime. In it, several sections are included (
Celia (virtual assistant)
Celia is an artificially intelligent virtual assistant developed by Huawei for their latest HarmonyOS and Android-based EMUI smartphones that lack Google Services and a Google Assistant. The assistant can perform day-to-day tasks, which include making a phone call, setting a reminder and checking the weather. It was unveiled on 7 April 2020 and got publicly released on 27 April 2020 via an OTA update solely to selected devices that can update their software to EMUI 10.1. Huawei had initially referred to the new assistant in late 2019 by having announced that there would be an English version of their already 2018 Chinese speaker assistant—Xiaoyi—to be released into the European markets. Due to the on-going China–United States trade war, the company's newly released smartphones were left without any Google services, including the loss of Google Assistant. This subsequently led to the development and release of Celia. AI technology is integrated into the software of Celia, which allows it to translate text using a phones camera and to identify everyday objects — similar to that of Google Lens. == Features == Celia has many features that are similar to that of its rivals: the Google Assistant and Siri. It can be triggered by the words, 'Hey Celia' or be summoned by pressing and holding down on the power button. The default search engine for Celia is Bing, but this can be changed in settings. Celia can make calls, check the agenda, send a message, show the weather, set alarms and control home appliances. The assistant also has the ability to integrate itself with the stock apps of the EMUI software and toggle with the device's settings, such as by turning on the flashlight and playing multimedia content, but with the users command. With the AI that is installed in Celia, it can identify food, everyday objects and translate text using the phones camera. In China, Chinese Xiaoyi packs with an LLM model called PanGu-Σ 3.0 AI on HarmonyOS 4.0 major upgrade improvements from Celia, making the assistant smarter and more advanced compared to when it was launched in 2020 on EMUI handsets in China and internationally, surpassing Apple and Google by the being the first in the AI industry, with a dedicated AI system framework of APIs on the latest operating system that evolves to a complete large dedicated AI software stack called Harmony Intelligence of Pangu Embedded variant model and MindSpore AI framework with Neural Network Runtime on OpenHarmony-based HarmonyOS NEXT base system to replace the dual framework system with a single frame HarmonyOS 5.0 version by Q4 2024, first introduced on June 21, 2024, in Developer Beta 1 preview release at HDC 2024. == Availability by country and language == Currently, Celia is available only in German, English, French and Spanish, and has been released in Germany, the UK, France, Spain, Chile, Mexico and Colombia. Huawei has said, that there will be more regions and languages to come. == Compatible devices == Celia only became available with the EMUI 10.1 update that was released in April, which means that a limited number of devices are compatible with it. More devices will be added to the list throughout the coming months as Celia's availability increases. The current list is shown below: === Huawei P series === Huawei P50 (Pro) Huawei P40 (Lite, Pro & Pro+) Huawei P30 (Pro) === Huawei Mate series === Huawei Mate 40 Huawei Mate 30 (Lite, Pro & RS Porche Design) Huawei MatePad Pro Huawei Mate 20 (Pro, 20X 4G, 20X 5G and RS Porche Design) Huawei Mate X & Xs === Huawei Nova series === Huawei Nova 6 (Nova 6 5G & Nova 6 SE) Huawei Nova 5 (Nova 5 Pro, Nova 5i Pro & Nova 5Z) Huawei Nova Y60 === Huawei Enjoy series === Huawei Enjoy 10S == Issues == Technology news website Engadget has noted that when saying, 'Hey Celia', out aloud in the presence of an iPhone, Siri will respond along with Celia; this is apparently because 'Celia' sounds similar to 'Siri'.
Document-oriented database
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
KE Software
KE Software is a formerly Australian-owned computer software company based in Manchester, United Kingdom, which specialises in collection management programs for museums, galleries and archives. The Axiell Group acquired the firm in 2014. == History == KE Software had its origins in investigations into electronic systems for managing natural science collections conducted in the late 1970s under a joint program of the University of Melbourne, the then National Museum of Victoria and the Australian Museum, which led to the development of the Titan Database in 1984. Much of the credit for the development of the project was due to the work of Martin Hallett of the Museum of Victoria which evolved into Textpress, and by 2000, the KE EMu database program. KE Software was bought by Axiell in 2014 and the team merged with the Axiell staff. Axiell continues to sell and support EMu. == Products == The firm has two main products: the Ke EMu Electronic Museum management system, a collections management system for museums; and Vitalware Vital Records Management System. The first version of Ke EMu was launched in 1997 and uses the Texpress database engine with client/server architecture on a Windows or Unix/Linux server. Ke Emu is consistent with the Dublin Core / Darwin Core standards for archive and museum catalogue metadata. "The company’s clients include the three largest museums in the world.: == KE EMu == KE EMu is considered one of the more effective and purpose-designed museum cataloguing programs. particularly in the creation of public interfaces to museum catalogue data. KE EMu was further developed in 1997 as a multilingual platform, which has been utilised in bilingual institutions such as the Canadian Museum of Civilisation. Subsequently this evolved into Texpress and KE EMu (standing for Electronic MUseum) in 2000, which is "now used across the world in natural science museums with huge collections'". KE EMu is used by a large number of museums and galleries around the world, including the Smithsonian Anthropological Collection, American Museum of Natural HistoryVancouver Art Gallery, New York Botanical Garden, the University of Chicago Research Archives, the University of Pennsylvania Museum in Philadelphia, the National Museum of Australia, the Australian Museum, Museum of Victoria, University of Melbourne Archives, and the Alexander Turnbull Library, National Library of New Zealand. There are over 300 clients, and more than 5000 users of the EMu software worldwide. The program has been described as providing "...comprehensive museum management (collection management plus other administrative needs for a museum), workflow and project management, flexible metadata, various stats and metrics, and comprehensive web interface with support for mobile devices and kiosks" == KE Vitalware == The firm's vitalware software is used by a number of governments and commercial organisations for managing and accessing large data sets, such as the birth records of the Trinidad and Tobago Registrar General, the Government of Anguilla, Ministry for Infrastructure, Communications, Utility and Housing, and the Mississippi Department of Information Technology Services. == Further development == A specialist tracking component for KE EMu has been developed by Forbes Hawkins of Museum Victoria. This enables locations to be barcoded, and data to be updated as items are moved around the stores, or between venues, display, laboratories and other locations. This system has been considered by Museums around the world. The company has been working with Australian government agencies to digitize birth deaths and marriage registers in order to cross match identity data. The program has also been used for managing the Australian Plant Disease Database and the Australian Plant Pest Database as the program "...has several features that have proven to be invaluable for a plant disease database".
Centurion Guard
Centurion Guard is a PC hardware and software-based security product, developed by Centurion Technologies. It was first released in 1996. There were several different releases and versions of this product, and many were distributed in computers donated to libraries by the Bill & Melinda Gates Foundation. == Operating system compatibility == Microsoft Windows 7 Microsoft Windows Vista Microsoft Windows XP
Database application
A database application is a computer program whose primary purpose is retrieving information from a computerized database. From here, information can be inserted, modified or deleted which is subsequently conveyed back into the database. Early examples of database applications were accounting systems and airline reservations systems, such as SABRE, developed starting in 1957. A characteristic of modern database applications is that they facilitate simultaneous updates and queries from multiple users. Systems in the 1970s might have accomplished this by having each user in front of a 3270 terminal to a mainframe computer. By the mid-1980s it was becoming more common to give each user a personal computer and have a program running on that PC that is connected to a database server. Information would be pulled from the database, transmitted over a network, and then arranged, graphed, or otherwise formatted by the program running on the PC. Starting in the mid-1990s it became more common to build database applications with a Web interface. Rather than develop custom software to run on a user's PC, the user would use the same Web browser program for every application. A database application with a Web interface had the advantage that it could be used on devices of different sizes, with different hardware, and with different operating systems. Examples of early database applications with Web interfaces include amazon.com, which used the Oracle relational database management system, the photo.net online community, whose implementation on top of Oracle was described in the book Database-Backed Web Sites (Ziff-Davis Press; May 1997), and eBay, also running Oracle. Electronic medical records are referred to on emrexperts.com, in December 2010, as "a software database application". A 2005 O'Reilly book uses the term in its title: Database Applications and the Web. Some of the most complex database applications remain accounting systems, such as SAP, which may contain thousands of tables in only a single module. Many of today's most widely used computer systems are database applications, for example, Facebook, which was built on top of MySQL. The etymology of the phrase "database application" comes from the practice of dividing computer software into systems programs, such as the operating system, compilers, the file system, and tools such as the database management system, and application programs, such as a payroll check processor. On a standard PC running Microsoft Windows, for example, the Windows operating system contains all of the systems programs while games, word processors, spreadsheet programs, photo editing programs, etc. would be application programs. As "application" is short for "application program", "database application" is short for "database application program". Not every program that uses a database would typically be considered a "database application". For example, many physics experiments, e.g., the Large Hadron Collider, generate massive data sets that programs subsequently analyze. The data sets constitute a "database", though they are not typically managed with a standard relational database management system. The computer programs that analyze the data are primarily developed to answer hypotheses, not to put information back into the database and therefore the overall program would not be called a "database application". == Examples of database applications == Amazon Student Data CNN eBay Facebook Fandango Filemaker (Mac OS) LibreOffice Base Microsoft Access Oracle relational database SAP (Systems, Applications & Products in Data Processing) Ticketmaster Wikipedia Yelp YouTube Google MySQL
Tactical NAV
Tactical NAV, also known as TACNAV-X, is a location-based tracking app designed for use by military personnel. The app is primarily designed to assist in pinpointing enemy fire and mapping waypoints. Tactical NAV also helps users efficiently relay critical information to tactical operations centers for prompt decision-making regarding airstrikes or medical evacuations. The TACNAV-X platform is intended to enhance situational awareness, refine navigation capabilities, and assist in tactical decision-making across various operational environments. == Overview == Tactical NAV allows users to pinpoint enemy fire. == History == Tactical NAV was designed by U.S. Army Captain Jonathan J. Springer, a Field Artillery officer serving as a Battalion Fire Support Officer (FSO) in the 101st Airborne Division. Springer conceived the idea for the app during his third tour in Afghanistan in support of Operation Enduring Freedom. On June 25, 2010, after a rocket attack by the Taliban killed two soldiers in his battalion, he was inspired to create an app that would prevent similar losses in the future, enhance situational awareness, and assist soldiers serving on combat deployments. In 2010, Springer founded TacNav Systems (formerly AppDaddy Technologies) to develop mobile applications for use by military personnel. He tested the app during combat operations in eastern Afghanistan and verified TACNAV-X's accuracy using DAGRs, AFATDS, Falcon View, CPOF, ATAK, and other approved Department of Defense (DoD) systems. As of 2012, the app had been downloaded 8,000 times.