Description of the Unified Listing
Key Pages for the Unified Listing
- Objectives of the Unified Listing - Including goals, users, and use cases
- Description of the Unified Listing- A natural language description of the structure and operation of the UListing '(On this page)'
- Specifications of the Unified Listing - Specifications for the Unified listing including fields, layers, functions etc.
- Federation of the Unified Listing - Listing of the databases that plan to federate with the Unified Listing
Description of the Unified Listing
This page provides a natural language description of the structure and operation of the UListing.
The proposed Unified Listing
The database will use a layered structure so that it has a single record for a product but a record layer corresponding to each of the databases with which it federates as well as for each record/language combination. By aligning them and giving them a common product identifier it is possible to provide only one copy of the product in search results even if it appears in many databases. Once the product is found, an individual can flip through the different descriptions of the product from different databases if they wish. Or look for a description in a language they are most familiar with.
The proposed database will allow users to specify preferred languages (multiple in a prefernce order if the searchers speaks multiple languages) and the database will automatically display results in the most preferred language that exists for that entry. (It will also auto-translate – but this is of less quality). Because of this ‘single record’ ability, the user does not need to find the same products repeated many times in search results.
Also, because of this feature is possible for differences between databases to be detected, and for corrections to be made by a manufacturer (or database curator) to multiple layers of a record (corresponding to different databases) at one time. The synchronization with the other databases will then return a corrected record to each federated database that would match the format for each of the different federated databases.
- For the fields are common, a correction need only be made once.
- Where they differ, the change on the Unified Listing may have to be made to different layers, but this is fairly straightforward for a manufacturer. (Much easier than going to each of the different databases providers and looking up a record in order to correct it.)
- Federation with the Unified Listing therefore will provide the ability to not just access the information in a unifed way - but also to have corrections that are made be automatically fed back to each of the databases that federate with it, either directly or with moderation, eliminating the need to reenter data.
- This approach also solves a major complaint of companies that often will not update any databases because they get requests from so many. The ability to go to one location and correct entries for their products and have it propagate to all of the other databases that are the original source of the information is of great interest to them.
One of the greatest benefits ofthe unified database is its unique coverage of not only assistive technologies but also the access features in mainstream products. The only comprehensive database where access features in mainstream products currently exists is the GARI database for mobile phones. No similar database exists however for anything outside of the phone accessibility features. The Unified Listing will provide information for the first time on both assistive technologies and on access features in mainstream ICT. It will also draw in the data from GARI. As a result, for the first time, users will be able to conduct a single search and find not only assistive technologies but features that exist in mainstream technologies that they would otherwise not be aware of. It will also help them to determine which of several mainstream devices might be usable directly by them. This work is being carried out in collaboration with, and with the support of, the Consumer Electronics Association.
To provide information in different languages the database will both store multiple languages for a record where they exist and couple with automatic translation engines to make it easier to serve information in multiple language. Current databases are usually available in only one or two languages. In fact the reason that many duplicate databases exist is because they are developed in different languages. The Unified Listing, with its multilayer data records, will allow viewers to store and present different language translations of the data. Crowdsourcing and the GPII document transformation pipeline can be combined to both auto-translate and have human correction of entries for people wishing to translate databases to their language, (or it can be done on demand with a slight delay for human double checking and correction if desired).
Important for sustainability, the Unified Listing has also championed a new practice wherein all federated database records that originated from another database are clearly marked as to their origin. The power of a truly federated database is the fact that the efforts to maintain the data can be spread across many database teams who then share the results. However, if the databases are anonymously federated, it can begin to look like all of the databases are redundant. This can cause some or most to lose their funding. Therefore the origin of the data is important to preserve. In addition the unified database will also track the number of times that data from another database was accessed in the Unified Listing. These usage statistics will then be fed back to the original source database so that that database can report not only the number of searches done on their database, but also the number of searches done on their data remotely.
- CLOUD4All deliverable D 203.1 that describes the mechanism for connecting EASTIN with the Unified Listing:File:D203.1. Mechanism for repositories federation FINAL.pdf
- Specification of the "output web services" for extracting data from EASTIN: Specifications_for_the_Output_Web_Services
- Algorithm for product similarity: an algorithm for comparing two records in order to evaluate the probability that they represent the same product: Algorithm_for_product_similarity
Accompanying the Unified Listing will be an Open Marketplace. Whereas the Unified Listing will be comprehensive, and list all products available from all vendors and marketplaces (e.g. the iOS App Store, Google Play, Microsoft's App store etc.) the Open Marketplace will only contain products that a vendor chooses to sell through the Open Marketplace. The purpose of the Open Marketplace is not to compete with the other marketplaces, or to carry a full range or as many products as possible. Instead the purpose of the Open Marketplace is to provide those individuals or companies who cannot market or market internationally themselves with an easy mechanism for selling their product internationally. This will include the ability to automatically handle the financial transactions needed to purchase products in currencies other than the manufacturer’s base currency. Where products are located in any of the app stores, users will be able to find them easily using the Unified Listing, which will then direct them to whichever app store the product resides. If it is in the Open Marketplace and someplace else as well, the user will directed to both. So the Open Marketplace becomes an extension of, or complement to, all of the other markets that are out there. However it is a market where users can upload and sell apps or program or services that cannot be listed elsewhere. Coupled with international translation tools for products being developed, the auto transformation tools and the multilingual website, the Open Marketplace also makes it easier for people to find products that operate in their language on a website that is presented in their language and in the form needed by them.