From wiki.gpii
Jump to: navigation, search

This is a glossary of key terms used in Cloud4all/GPII

If you don't see a term that you feel should be here you can

  • enter the term below,
  • or send a note to

If you have a suggested definition - please

  • put your proposed definition below with << double angle brackets >> around the definition
  • or include that in your email to Kasper

OLD IGNORE -- > The formal internal glossary for inclusion into project deliverables is available at: (needs syncing from time to time)

Thank you


This Glossary consists of two parts

  1. an alphabetical list of terms
  2. extended definitions/descriptions of key terms/concepts in Cloud4all/GPII

Glossary Workspace

We are currently working on our vocabulary to bring together work from different groups and to prepare for the new Prosperity4All Project. This work can be found in the GLOSSARY WORKSPACE.

GLOSSARY (Alphabetical)


  • Adaptive user interface: "Adaptive User Interfaces are user interfaces that adapt their appearance and/or interaction behaviour to an individual user according to a user profile. In contrast to adaptable user interfaces, which are modified by a deliberate and conscious choice of a user, adaptive user interfaces automatically initiate and perform changes according to an updated user profile." (source: VUMS Cluster Glossary of Terms)
    • NOTE: We do not use "user profiles" or "user models" to adapt user interfaces but rather "user preference sets". Cloud4all/GPII also blurs the line between adaptable user interfaces and adaptive user interfaces because the infrastructure (which is part of the overall "user interface") will be changing the user interface (rather than the local user interface adapting itself). Over time designers will be counting on the infrastructure when they design the local interface. So it becomes ambiguous whether an interface that is designed to be adapted by the infrastructure is an adaptable or an adaptive user interface?
  • Adaptive AT, Adaptive Assistive Technology: "Assistive technology that makes other software accessible that otherwise was no. For example, a screen reader, an alternate keyboard, etc.
    • Note 1: A good test of whether something is Adaptive AT is that its primary purpose is not to provide any function itself other than providing access to other software.
    • Note 2: Adaptive AT is in contrast to Purpose-Built AT - such as a calculator designed specifically for people who are blind.
    • Note 3: Some AT may be hybrid and BOTH provide access to other software, AND provide some basic functionality itself. (e.g. an adaptive keyboard with built in calculator or calendar or other function designed specifically to be easier to use for people with disabilities.
  • APfP: Auto-personalisation from preferences.
  • Application-specific preferences: preferences that are used by a specific application. These can be terms that have exactly the same meaning as COMMON FORMAT TERMS, term that 'are' COMMON FORMAT TERMS, or terms that are different in some way from COMMON FORMAT TERMS (e.g. different value space), but they are the actual terms used by a specific application. These would also include any APPLICATION-UNIQUE PREFERENCES.
  • Application-unique preferences: preferences that are only used in a specific application and do not make sense outside of that application. For example, XYpositionToolTray12 which an application might use to store the last location on the screen that a person positioned one of the application's tool trays.



  • Condition (in Condition Registry): "a term used to qualify whether Need/Preference would or would not apply. Note that many settings serve both as preferences and conditions for other preferences."
  • Context: "information about the surroundings of a person's interaction including the physical environs, social situation, task at  hand, situation of the device being used, other applications on the device etc".


  • Discovery Tool: <<Tool used to discover a users needs and preferences.  It can take many forms but the classic form is one that assumes nothing about the user and through a series of questions and exercises discovers what a user needs with regard to interface characteristics or access features in order to use ICT.  The classic form also assumes digital illiteracy so it does not use computer metphors or widgets confining itself to controls that exist in the physical world but that can be controlled easily by all disabilities.  It also does not assume any ability to read, to see or to hear.  People with disabilities that cannot be accommodated with the IO on a typical advanced computer may not be able to succeed with a discovery tool.      See also PMT (Preferences Management Tool) which is used by people (who are able) to explore their settings or additional settings once they have a Needs and Preference Set.  >>


  • EASTIN Classification of Assistive Technology
  • Ecosystem A complex system of interacting entities that depend on each other and, in balance, support each other’s existence.   Ecosystems involve competition and predation, but in balance the whole ecosystem works or collapses. (The Access community of developers, customers, funders, and policy person etc  - is an ecosystem) 


  • Gamification: "Using game-based mechanics, aesthetics and game thinking to engage people, motivate action, promote learning, and solve problems" [1]
  • GPII-Logs or G-Logs: Logs created by the GPII-App about the internals of the application. They are meant for aiding the debugging of the application and troubleshoot any issues.


  • Implementers: vendors and persons providing applications, tools and services to end users adapted to their needs
  • Infrastructure   Something that this is constructed to support a greater entity or system (The GPII is an infrastructure, the Developer Space is part of that infrastructure)


  • Journal or Journaling: See Recovery-Journal


  • Key   Code that is used to point to a preference set.
    • Keys can be stored on physical objects (see KeyToken) or can be virtual (e.g. preferenceSetName and PW) or biometric (Face, Voice, Fingerprint, VeinPrint etc).
    • Keys often have a URL pointing to the PreferenceServer chosen by the user, and a long unique string.
    • Keys can have lookup strings that change with each use or change based on time. A special server decodes that string to identify the preference set lookup. YubiKey is an example of this.
  • KeyToken   Any physical object that carries a Key. KeyTokens can be USB devices, NFC devices (stickers, cards, rings, cellphones, etc), QR Codes, etc.


  • Logs: See Metric-Logs, GPII-Logs or System-Logs


  • Metrics-Log or M-Log: Logs created to support the APCP metrics required by project proposal. These logs are meant for feeding some statistics of the APCP, and only shows anonymous metrics of the use of some features.


  • Persona: "personas are fictional characters created to represent the different user types within a targeted demographic, attitude and/or behavior set that might use a site, brand or product in a similar way." (Source: Wikipedia)
    • Note: Alan Cooper introduced personas in The Inmates Are Running the Asylum; he based his personas on research, observation and conversation with users. Personas were not meant to be simply documents or "deliverables". See Andrew Hinton: "Personas and the Role of Design Documentation", Boxes and Arrows, 26 February 2008.
  • PCP - Personal Control Panel: "a small tool that is always visible (on larger screens) or can be invoked with a single action (for smaller screens or non-visual access) that allows users to change the accessibility setting on a device in real-time as they use it. The controls showing on the PCP are custom (just the controls a user wants) and are the controls the user needs on a constant basis while using the device (like zoom, or speech speed or captions on/off or position to keep captions from covering other information). The PCP does not affect the users stored preferences directly (though other systems may monitor the PCP behavior and do so (with user permission/preference setting). The PCP may have links to launch other systems. (see also PMT.
  • Platform A platform is a group of technologies that are used as a base upon which other applications, processes or technologies are developed
  • PMT: (See Preference Management Tool)
  • Preferences Management Tool (PMT): " tool for managing the Need and Preferences file"
  • Preference Set: "a set of user preferences"
    • Preference sets usually are stored in the cloud on a Preference Server.
    • Preference sets CAN be stored on KeyTokens directly, but loss of KeyTokens would be loss of preferences sets.
    • Multiple KeyTokens can point to one preference set. This is often done for anonymous preference sets so that loss of one key does not mean loss of access to the preference set.
    • SnapSets are a special "pre-defined" preference set. (see SnapSet)
  • Preference Tool: "tool that is used to create, view, or edit user preferences"
  • Preference Terms Dictionary (PTD, formerly known as Registry of Common Terms (or of Common Vocabulary Items)): <<"a database of terms with definitions and value range that can be used in forming needs and preference statements. The terms include (but are not necessarily limited to): words used singly or in combination to represent Needs and Preferences, words used singly or in combination to identify conditions, and operators (AND, OR, NOT). See Common Terms Registry.
  • Purpose-Built AT, Purpose-Built Assistive Technology: "Assistive technology that provides some basic function usually available to people without disabilities, but is designed specifically for people with one or more disabilities makes other software accessible that otherwise was not. For example, a screen reader, an alternate keyboard, etc.
    • Note 1: A good test of whether something is Purpose-Built AT is whether is provides a function itself (vs Adaptive AT that is designed primarily to provide access to other software.
    • Note 2: Purpose-Built AT in in contrast to Adaptive AT - such as a screen reader designed to provide access to other software.
    • Note 3: There is a blurry line between purpose-build AT and Universally Designed or Inclusively Designed mainstream products since these provide both function and interfaces designed to accomodate people with disabilities.


  • Recovery-Journal: Known in computing as "Journal". A special file called used to repair any inconsistencies that occur as the result of an improper shutdown of a computer. It keeps track of changes by recording such changes in a data structure known as a "journal".
  • Registry of Common Terms: see Preference Terms Dictionary.
  • Resources: information, materials, staff, and other assets that can be drawn on by a person or organization in order to function effectively.   (as in Developer Space/Resources : documentation and human resources that support building AT and accessible IT)


  • SnapSet: a predefined preference set
    • SnapSets can be shared SnapSets (which are by definition fixed since many people are using them) or they can be loaded into user-modifiable accounts where they serve as starter sets which the user can leave unchanged or adapt and extend to create their own custom preference set.
    • SnapSets are not physical things - they are predefined sets of preferences stored in the same way as any other preference set
    • Multiple Keys/KeyTokens can point to the same SnapSet. (just as multiple Keys/KeyTokens can point to any preference set)
  • Solution: a product, service, or feature that addresses a barrier faced by someone due to their disability, literacy, digital literacy or aging.
  • Solution Registry: a machine readable registry of all of the solutions that have been onboarded and work with the GPII
    • The registry contains all of the information needed by the GPII auto-personalization software to be able to find, save, change, or restore each setting of each feature for each product or service that GPII can set.
    • It also contains GENERIC settings - that do not apply to any particular product but can be used when no product specific setting preferences are provided
    • The information in the solutions registry includes, but is not limited to,
      • the machine readable name for each version of a product that has a different feature or setting or value range or default values etc
      • for each version
        • The UID in the Unified Listing
        • the machine readable ID for each of the GPII settable settings
        • the data type
        • the value range
        • the default value
        • transformations to and from generic values
  • System-Logs or S-Logs: Logs created by the Operating System and/or the infrastructure that supports the GPII, which are not part of the Metrics-Logs or the GPII-Logs.



  • User model: "An (abstract) User Model is a set of user characteristics required to describe the user of a product. The characteristics are represented by variables. The user model is established by the declaration of these variables. It is formally described in a machine-readable and human-readable format. An instantiation of the user model is a user profile." (source: VUMS Cluster Glossary of Terms)



Overview of registry, user preference set and context

Error creating thumbnail: Unable to save thumbnail to destination

User Preference Set

A user preference set consists of a flat ordered list of user preferences.

User Preference

A user preference consists of three fields: a property, a value and a condition. The property serves as a key to get a specification from a registry, which defines the user preference (for example by defining the value space for the value field).

Inferred Preferences

The "user preference set" contains ONLY preferences set or verified by the user. Preferences which were inferred by a MatchMaker are not stored in the "user preference set", as they are MatchMaker specific and using multiple MatchMakers at once would cause problems. If a user verifies and confirms an inferred preference through any means, it may be added to his/her user preference set.


A preference server may support keeping track of old values in a preference set. This might be useful for some matchmaking tools.


An identifier for a Preference. Properties (namespace + local name) should be unique (URIs) and identify the field the value of a Preference applies to and defines it value space. They are organized in the Registry.

  • Properties can be certified or non-certified.
  • A properties is "atomic" because it can not be broken down into subcomponents. Example: font size.
  • Properties are tied to existing metadata standards when possible. For example, properties may be associated with existing Dublin Core terms.

Note: Add a section on "Terms". A COMMON TERM is a "property + specification" in the registry.


Conditions are unique to the user preferences and define their circumstances of application. A preference could, for example, only be active at a given time of the day (global sensor), at a given lighting condition (local sensor) or on a certain operating system (device specific).

Conditions are a means of collapsing many preference sets for a user, each of which is applicable to a single situation (combination of device and context properties). A condition "unfolds" its preference-value pair resulting in a (possibly infinite) number of preference sets that include specific values for contextual parameters.

We are currently exploring how to 1) express conditions,  2) store conditions and 3) present conditions to the user.

One proposal was to use boolean operators.   However there is concern about using unbounded use of boolean operators.  Work is continuing.  

<move the following to a subpage and link to it>

Conditions are expressed as Boolean expressions, featuring the common logical and comparison operators (incomplete list, you could also imagine string comparison operators like "contains"):

Operator Description
&& binary operator: logical and
|| binary operator: logical or
! unary operator: logical not
== binary operator: equality check. This operator is specified in the specification received from the registry
> binary operator: greater-than check. This operator is specified in the specification received from the registry
< binary operator: less-than check. This operator is specified in the specification received from the registry
>= binary compound operator: (a >= b) --> ((a > b) or (a == b))
<= binary compound operator: (a <= b) --> ((a < b) or (a == b))

There are also some functions available to receive values.

Function Arguments Description
value(uri) uri (datatype: string): a property Returns the value of a user preference or a context property in the current user preference set or context set. Note that these values must be determined at runtime.
isKnown(uri) uri (datatype: string): a property Returns a Boolean indicating whether the passed property appears in the user preference set or the context set


A Context consists of a flat unordered list of Context Items.

The Context describes the current context. This includes output from local sensors (like the current background noise), global sensors (like the current time of the day at the device's location) or device specific information, like the device type or the operation system version, and information provided by the user (e.g. "I am tired" or "I am at home").

Context Item

A context item consists of two fields: a property and a value. A property may only appear once in a Context Set. The property serves as a key to get a specification from a registry, which defines the context (for example by defining the value space for the value field).

A context item may change at runtime, even during a session. For example, the current time will change frequently.


MatchMaker Infrastructure

Error creating thumbnail: Unable to save thumbnail to destination
  • Matchmaker storage is specific to matchmaker.
  • Ethical implications of a matchmaker storing inferred preferences.

MatchMaker Input

  • Current "user preference set" from the Preference server containing only preferences set or confirmed by the user
  • Query which Properties are requested

MatchMaker Storage

Most MatchMakers will require to store their own data about a profile. For example cached results, inferred Preferences or results of a statistical analysis. The MatchMaker itself is responsible for storing and organizing this data. It is recommended to use a single DB, filesystem or something similar for this purpose (for maintenance reasons).


Ontologies may link to the registry or other pieces or products of the infrastructure, but the whole Cloud4All infrastructure and any of its components does not link to an ontology to perform its tasks.

A matchmaker may use any kind of ontologies, including metadata schemes.

Classification of Assistive Technology

EASTIN Classification of Assistive Technology

Classification of AT products, based on the ISO 9999 standard, available on the EASTIN website. Assistive products are classified according to their main function. The classification consists of three hierarchical levels (standardization for a 4th level is ongoing). ICT products mainly belong to classes 22 "Assistive Products for Communication and Information" and 24 "Assistive products for handling objects and devices"

See Also