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 Kasper@raisingthefloor.org.
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
The formal internal glossary for inclusion into project deliverables is available at: http://tinyurl.com/GPII-GLOSSARY (needs syncing from time to time)
- 1 Organization
- 2 Glossary Workspace
- 3 GLOSSARY (Alphabetical)
- 4 EXTENDED DEFINITIONS/DESCRIPTIONS OF KEY TERMS
- 5 Overview of registry, user preference set and context
- 5.1 User Preference Set
- 5.2 Context
- 5.3 REGISTRY
- 5.4 MatchMaker Infrastructure
- 5.5 MatchMaker Input
- 5.6 MatchMaker Storage
- 5.7 Ontologies
- 5.8 Classification of Assistive Technology
- 5.9 See Also
This Glossary consists of two parts
- an alphabetical list of terms
- extended definitions/descriptions of key terms/concepts in Cloud4all/GPII
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.
- 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.
- Note1: 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.
- Note2: Adaptive AT is in contrast to Purpose-Built AT - such as a calculator designed specifically for people who are blind.
- Note3: 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.
- 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 no. For example, a screen reader, an alternate keyboard, etc.
- Note1: 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.
- Note2: Purpose-Built AT in in contrast to Adaptive AT - such as a screen reader designed to provide access to other software.
- Note3: 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.
- 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".
- Components: (as in Developer Space/Components) general term used to describe Building Blocks, Frameworks and Services that can be used by Implementers to build AT and accessible mainstream IT.
- Developers: are people contributing Developer Space Components, frameworks or other Developer Space Resources (in contrast to Vendors and Implementers they are not necessarily servicing the needs of End Users)
- Developer Space Repository: A part of the Developers Space that links Developer Space Components and acts as "matchmaker" between Vendors and Implementers and Developers
- 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 acoomodated 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
- Gamification: "Using game-based mechanics, aesthetics and game thinking to engage people, motivate action, promote learning, and solve problems" 
- Implementers: vendors and persons providing applications, tools and services to end users adapted to their needs
- 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.
- PMT- Preferences Management Tool: " tool for managing the Need and Preferences file"
- 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.
- Registry of Common Terms: see Preference Terms Dictionary.
- Resources: (as in Developer Space/Resources) documentation and human resources that support building AT and accessible IT
- 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)
- Virtual user: "A virtual user is a representation of a user based on a user profile. (...)" (source: VUMS Cluster Glossary of Terms).
EXTENDED DEFINITIONS/DESCRIPTIONS OF KEY TERMS
Overview of registry, user preference set and context
User Preference Set
A user preference set consists of a flat ordered list of user preferences.
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).
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"):
|&&||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.
|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").
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.
- SEE REGISTRY.
- Matchmaker storage is specific to matchmaker.
- Ethical implications of a matchmaker storing inferred preferences.
- Current "user preference set" from the Preference server containing only preferences set or confirmed by the user
- Query which Properties are requested
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"