Common Terms Registry

From wiki.gpii
Jump to: navigation, search


The purpose of the Common Terms Registry is to encourage and enable all stakeholders to use the same terms when describing the same things (i.e. using the same term for the exact same concept and same value range). This Common Terms Registry is designed to be used for term related to User Needs and Preferences for product and material interfaces (e.g. I need fonts to be larger than X, or I need all information to be presented non-visually, or I prefer this type of magnification, etc.) Using common terms for the same things facilitates the ability for users to transition between products, to use new products they have never encountered, and to call on machine assistance for new products and new situations as they encounter them. It also facilitates the use of common code modules, reducing the cost to create and support new types of products (both assistive and accessible mainstream).

A second purpose of the Common Terms Registry is to record aliases and transformable aliases so that terms the are different, but equivalent (or transforms of each other) can be easily located and understood to represent the same concept. This enables many of the same benefits as above.

The Common Terms Registry currently includes:

  • General Terms - including their Name, Description and Value Range
  • Aliases - terms that are identical in all respects to the General Terms except that a different term (Name) is used
  • Alias Transforms - Terms that are identical except the value range is a transform of the general term (e.g. inches instead of cm or log of x instead of x)
  • Translations - identical to General Term except that it is translated into another language
  • Operators - a set of terms that can be used in Needs&Preference Statements that will be understood by all User Needs&Preference Tools

Uses of the Common Terms Registry include (but are not limited to):

  • terms used to construct metadata for media, materials, access technologies and access features
  • terms used to construct needs&preference statements (which are stored and used to choose best fit solutions when multiple are possible)
  • terms used by developers to describe the settings and user interface options for their products
  • terms used by matchmakers to find best match between what is possible and what is desired by user for any media, material, resource, or device.
  • terms used by products themselves in the absence of a matchmaker - to determine best interface for a user (built-in matchmaker function).

Example: In GPII - users describe their needs and preferences, which are captured using these common terms and stored locally or in the cloud. Manufactures either use the common terms to describe their settings, or they register their terms and provide transforms to the common settings where applicable. The settings the product is capable of are stored in the Solutions Registry (part of the Unified Listing). When a user encounters a new piece of technology (or a new configuration or screen size etc. of an old technology) the GPII matchmakers understand both what is needed/desired (from user needs and preferences) and what is possible (from the Solutions Registry), and - because of the use of common terms - it can (by rules or statistics) determine appropriate settings for the new technology/configuration so that the person can use it.

Acknowledgements: The minimum required fields and procedures entry and maintenance of the Common Terms Registry are being defined by the new ISO 24751 REVISION now underway. The COMMON TERMS REGISTRY is being built under the Cloud4all project funded by the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement #289016. The ongoing maintenance of the COMMON TERMS REGISTRY is being carried out by Raising the Floor - International (


Kasper posted a note calling for a meeting to discuss the need for Common Terms Work -- in the Cloud4all context.

24751 Standards work


This document describes the Common Terms Registry.

  • Aliases:
    • Registry of Common Terms
    • Descriptive name: Registry of Common Terms for use in describing and matching needs/preferences/permission to available materials, settings, solutions (devices, software, services)


In the below a description of the data contained in the registry can be found; for information about the the technical specifications and implementation of the underlying database, see: Registry - database planning

    • Flat
    • There is one entry for each COMMON TERM   (this is a REGISTRY of COMMON TERMS)
    • The common terms may be used in different ways. For example any term could be used in describing one or more of the following
      • type of solution   ( software, service  )
      • aspect of solution  (setting, feature )
      • aspect of device   ( feature, constraint, status )
      • aspect of environmental  ( lighting, auditory )
      • measurable or reportable (by user) aspect of user  (e.g. status: tired,  excited (where this would affect abililties) )    <we need to think about this one>
      • Other context  ( time of day,  )
    • Each record has the following fields.  The table lists the fields and which ones are used when the COMMON TERM is used in different ways
    • (in the end it may turn out that all uses use all fields but this is to determine that) 
  • Application UNIQUE Terms
    • Included in the CT Registry if the manufacturer desires.  It would be in the Mfg-Controlled category
    • It is included in the database structure because the same term might be used by others-- and may indeed have general applicability.  It will be easy to filter them out. 
    • For example - "ToolBox#4Position"   or  "ToolBox#4Size"  for a specific application "ZergoWriter" might store the position the user want this toolbox to appear on screen or How large it should be.  This term may be used by multiple products from that manufacturer but would not make any sense to others.   If ZergoWriter is massively popular however, rules might be written for matchmaker saying what to do with this ToolBox on different sized screens etc. 

Implementation Notes

  1. Should have a way for companies to pull the whole database down easily.
  2. Should build first with utilitarian interface -- and not wait for a well designed one -- so that other CFA teams can begin to populate it. 
  3. Should build the API early so the ontology teams can start linking to it.


  1. Privacy?
  2. Run time use of identifiers? 
  3. Defaults -- drop them?
  4. Confirming that no ontology in the CT Registry itself
  5. Review Fix to TRANSLATION term problem --  adding new column -- to allow defintiions to be translated.  also address translations of enumerated value spaces. 
  6. how to handle     uppercasePitch ---    as  one term ?   or two     uppercase (condition)    and  pitch  (setting)    -- and if so how do we alias  uppercasePitch to the two terms
    1. this differs from keyEcho and  wordEcho that would be two terms  not condition and term

Aliases, Translations, and Transforms

  1. There will be Aliases -- which are exact duplications of a full Common Term - including all fields  (except perhaps notes on where/how they are used)
  2. There will be Translations (a type of alias in effect and reality)-- which are exact duplications of a Full Common Term except that it is in another language  
    • (Value Space is identical and, if enumerated, has one-to-one value matches -- with only change being the language
    • Different measurement systems (cm vs inch) are handled as Transform-Aliases
  3. There will be Transform-Aliases  where the term is an exact duplicate for a Full Common Term  except that there is a   Bidirectional,  Lossless, Algorithmic Transform for the Value Space
    • ​The transform algorithm  (format and technology are yet to be defined)  
    • (we will NOT be including the transform algorithm as part of 24751.   We will only say say that an entry type of Transform-Alias  exists and that the transform is described in the entry)

items marked  ** and in red would be in/required by the standard  24751.   (other fields can change as needed)

FIELDS   (* Means Translated versions are also in database (

''''** has to do with whether they are in named in the 24751 standard 






etc. (new)


** Type
The type of entry -  see columns and text on this page for how the entrie types differ

Enumerated Values 

  • ALIAS 

Permanency  ???    (was  CORE but that term has other meanings in the field) 

Candidate Names -->  Stability, Permanency, Reliability, Consistency,  Fixedness, Changeability,   

  ( a REGULAR rating is easy to achieve;  anything not duplicative, not destructive/disruptive)  

@@@ There is a question as to whether this field is needed.  Once a term is registered -- is it not frozen?  If not, how could anyone or any tool rely on it? 

Enumerated Value

  • Certified,
  • Regular,
  • Mfgr-controlled
Inherited Inherited X (only Certified?)

** NameSpace  
          NameSpace is "GPII" for all REGISTRY defined terms.  I would be different terms that are controlled elsewhere - such as entries that are controlled by a manufacturer.)  

Text field validated as URI X X X (only URI for CT REGISTRY?)
**  Term      This is the name of the setting/preference/operator.  This is in english (unless it is an alias or translation)

** UniqueID  
          This is created from  NameSpace+Term+LanguageTag  

Text - validated  as:
-  English: single word lowerCamelcase
Non-English: append an underscore followed by a language code, as in uniqueId_languageCode.  

** Language    Language of description and label of this entry Language coded per ISO 639-1

** TranslationOf *  
          The uniqueID of the canonical English record that this translation refers to.
Text - validated
as single word
X <illegal> <illegal> <illegal>
** ValueSpace
          (Table of LocalizedNames* for Enumerated Values)
 SEE "VALUE-SPACE" BELOW THIS TABLE Translation of any enumerated values, dimensions, etc
that are language specific


<span style="color:#ff0000;"</span><span style="color:#ff0000;"</span>

For Transform-Alias
there is a bidirectional lossless algorithm here

X <illegal>

DefaultValue used most  

           (this is informative only)   This info should be collapsed into the notes field over time since different companies may use a different default valued for  a term or an alias - and there are no cannonical default values.  

Value defined by  ValueSpace Translation of any language specific enumerated Default values,   ? X <illegal>

          (only used if term is an Alias -  OR  if it is an AliasTransformation and if there is a bidirectional lossless transformation algorithm in the Value Space)

The uniqueId of the canonical record that this alias refers to.

Text Validated to be an existing UniqueID that is not an alias. <illegal> X <illegal> <illegal>
TermLabel *    
          (not camelCase)   (Label as would appear in a menu or listing)
Text X X X <illegal>
** Definition *  
          Open text field describing the term.    (Mfgrs might list the products they use the term in in mfgr-controlled term)
Text X <illegal>   X X
** Notes *    
          (including Source if borrowed from another language)
Text X X X X

Application Unique Flag
         (Simple true false flag for settings that are believed to be unique to an application and of no use elsewhere)   (Alias because company may change name with new version of product)

True/False X


X <illegal>
          A notes field that describes which other systems use this term and may include structured information about the ontology for that use. (This is a temporary field to preserve source data while building the database.  The unified listing will remove the need to retain this data except for standards or other non-product uses.)
Text X X X <illegal>
          (used internally for processing  -  not necessarily public)

Enumerated Value
(not standardized) Currently used values:

unreviewed = new record

active = reviewed and active

trash = inactive and not visible


FIELDS   (* Means Translated versions are also in database (

''''** has to do with whether they are in named in the 24751 standard 



etc. (new)


Examples of how the fields are filled in 

XXXXXX   indicates a field that is not LEGAL to have a value for this TYPE of entry

  Text            GREEN text is REQUIRED for this type of entry


Regular, Stable PTDR Term

Alias of the same term & valuespace

Same term but diff langauge

Same exact term but different valueSpace with values = 0 to 400

Same idea but diff language and diff valuespace

Term used by a single Company - which they might change at any time

** Type


Alias Translation AliasTransform ???????   Regular 
** Permanency 

Certified (Stable)

Regular Regular Certified (Stable)


speechRate speechSpeed

** UniqueID  



** TranslationOf *   XXXXXX XXXXXX speechRate

** ValueSpace 0 - 1000   WPM XXXXXX

DefaultValue used most   (suggested) 


**AliasOf =

XXXXXX speechRate

TermLabel * (suggested)    
Speech Rate Speech Speed

** Definition *  
The rate at which speech is spoken expressed in words per minute XXXXXX

** Notes *     This term 

Application Unique Flag


Uses List of standards and products this exact term found is in.     List of standards and products this exact term found is in.






This entry in the database has to handle a wide variety of data formats. It needs to describe range, resolution, single/multiple value, Table of LocalizedNames* for Enumerated Values, etc.

One possible approach is to have the format be a table with the first entry specifying the type of table.

  • UNIQUEID of the enumations is the parentItemUID-enumerationUID
  • First Entry (types of tables)
    • Enumerated Values   (rest of table are choices of LocalizedNames)
    • AnalogSetting :  next cells would be   MAX, MIN, RESOLUTION, UNITS
    • IntegerSetting:   next cells would be  MAX, MIN, UNITS

We should / will look for existing standards or methods for doing this. See the thread started on 18 February 2013.

We can't predict all the kinds of data that will be stored in preferences; these data may include preferred fonts, JAWS scripts, vocabularies, etc.

Proposal for Declarative Preference Conditions Datatypes


  1. New term that is = to a Certified Term Definition and Dimensions
    • handle with Alias
  2. New term that is = to a Certified Term Definition but different Dimensions/Values
    • handle with Alias with transform
      • transform stored Solutions Registry (tentative solutions)
  3. OLD term -- but just new Enumerations
    • add them as new enumeration terms for that OLD TERM
      • start as new entries and be certified as enumerations for that term over time
  4. (same as ii but there are new enumerations --  extension
    • handle with Alias  and enumerations handled per iii
  5. New term = Certified Term but  DIFFERENT DEFINITION (and maybe Dimensions)
    • HAVE to have a new UniqueID in the CT Registry - done by adding mfgr or product to the UNIQUEID (mfg chooses?)
    • IF THEY WANT to work with GPII beyond just saving the specific settings then they need to provide a MAP to the UNIQUE ID
      • MAP between product settings and the  CT Registry UNIQUEIDS
        • also the place where you identify Product Unique Terms
      • MAP (or rather UNIQUE IDs) are needed for
        • Matchmaker
        • Transformers
        • Preference Editors  (to show choices and results)
    • MAP stored in Solutions Registry

NEED definitions/entries for Enumerated values that don't have Unique World Definitions (like state names)

  1. First turn to standards and pick one?
    • ISO 3166-1 lists two-letter codes for countries, three-letter codes for countries, and numeric codes for countries, dependent territories, and special areas of geographical interest. ISO 3166-2 covers codes for country subdivisions and ISO 3166-3 covers codes for formerly used names of countries.
    • Use MAPs to map any other terms (custom or other standard) used by products back to our chosen standard
  2. If no existing standard --then we look at what is used -- and pick a set based on whatever seems right at the time (best terms, most used, etc.)

How do we hande terms that are a combination of other terms

  1. This and any other transforms between common terms would be stored in a Common Transforms Registry  (tentative solution)
    • One alternative would be to store alias transforms in the valuespace of the alias but then it wouldn’t cover transforms between two full entries (though if there was an alias transform you wouldn’t have/need any ).
    • 'The Common Transforms Registry allow two terms to be CERTIFIED and yet be an alias of each other.' 


this is not controlled by user -- and is USED by conditions but is not one -- so does it belong in this Database.   it DOES have to be unique and standard and IS used in evaluating needs and preferences (e.g. a person may only have permission under certain circumstances like location)

What is:

  • User Need/Preference/Permission Set
    • This is what used to be called a User Preference Profile.  It is a set of preferences (for solutions and/or settings) that a person needs or prefers along with permissions (to use commercial or restricted solutions). A person may have many sets that they define for different uses, locations, tasks, levels of fatigue, or any other dimension where they 
    • See also: User Needs and Preferences Set
  •  ISO 24751 REVISION
    •  ISO 24751 is a standard also referred to as Access For All that <need good short description here>.
    • ISO 24751 is currently undergoing revision to move to this new REGISTRY format.  For more information see  <what is the best URL for overview of status etc?>

Why is?

  • Why is it important for stakeholders to use common terms?
    • If everyone uses the same terms, then it is easier for matchmakers to understand the meaning of the terms and to
      • adjust them when new conditions occur, or
      • translate them when a new device occurs, or
      • merge them if multiple people must use a device at the same time
  • Why is the term PERMISSION introduced here
    • Some solutions (software or services) require permission in order to use them.   Either they are commercial and the user needs to have paid for them (or someone has to have) or they are restricted for some reason (only people with certain qualifications can use the service) (e.g. belong to a class like 'legally blind" or "belong to XXXX Church which provides the service"). The permission is needed both by the matchmaker to know that that solutions is available to the user (perhaps only in that environment) and by GPII to invoke the service.

Q & A

What type of database will this be?  and Why?

It is a flat document store.  In addition to the TERM records,  there will be translations of some of the fields in the TERM records.   The ValueSpace field may also have enumerated values that will also have translations. 

Will the data in the REGISTRY be stable or changing?

 This is like a dictionary and individual TERMS should be stable and not change much.  But the REGISTRY will be dynamic in that new TERMS will be added continually going forward.  

Will it have a user interface?

It will have many different interfaces for viewing -- including via a number of ontologies.

There will be fewer for entry/editing.

If so, do we know what it might look like?

Not yet.

Will people be able to browse and search through the registry?

Yes using a number of mechanisms or tools - each designed for different user types or query types..

And will they be able to edit registry terms?

People who are registered contributors will be able to add terms (mostly developers).

Only a select editorial committee will be able to edit them.

Will there be accounts, groups, and permissions?


How about versioning?


We need to be able to keep a record of edits and who made them when.

Wiki Categories