Preference Terms Dictionary

From wiki.gpii
Revision as of 10:23, 17 April 2015 by SteveLee (talk | contribs) (Contributing to the PTD)
Jump to: navigation, search

The Preference Terms Dictionary or PTD is an open tool for managing preferences and settings used by the GPII. It can be accessed at

Note this tool was originally referred to as the Common Terms Registry and there are still some references in this wiki under that name.


One of the main components of the GPII is the infrastructure that provides Automatic Personalisation from Preferences (APfP). For this to be successful it must be possible for users to declare their preferences (eg high contrast display) and for the system to be able to match them to settings supported by the actual device the user is accessing (eg HighContrastTheme). In particular we require a scheme to group and map all the available settings supported by accessibility options and Assistive Technology (collectively know in the GPII as "solutions"). At a minimum we need to map differing terms (names) and dissimilar value ranges for the same concept. In addition, we'd like to pick a "master" or "common" term for general use when referring to a specific concept like "contrast".

Several activities have already tackled the need for organised naming of preferences. Of the various standards being tracked and informed by the GPII the most relevant for the PTD is "ISO/IEC 24751: Individualized adaptability and accessibility in e-learning, education and training". This consists of: Part 1: Framework, Part 2: Need and Preference Terms Registration and Part 3: Core Application Profile.


The PTD is an open web tool designed to provide a reference and allow the crowdsourcing of preference terms and their relationships. It provides a central reference point for use in the GPII and by others interesting is terms, for example users and solution developers. At the time of writing the tool is in active service, though it is fairly new and evolving as initial terms are being added.

For example the PTD entry for contrast clearly shows related terms and values. Note Editors can log in and see more detail for each term.

Use cases for the PTD

The anticipated user roles for using the PTD are:

  • Indirect users/beneficiaries — Users of the APfP who end up using the PTD terms data without ever knowing it. They use their KeyToken and up comes their AT configured to their needs/prefs.
  • Reference Users — People who refer to the PTD to learn about terms or look up something. This is largely a read-only activity
  • Contributors - People who are submitting new terms to the registry. Submission may be indirect, perhaps using forms that have supporting instructions.
  • Editors - People who actually enter and edit data in the PTD

The PTD is OPEN so that anyone can access the content and submit entries.

Soon a review workflow will be introduced for new entries (likely to be based on this suggested process). New entries from contributors will to go moderators/editors who will clean up, complete and then active entries. Editors will probably be relatively few in number since the role will require a fair amount of training and knowledge of the PTD to keep it consistent and useful.

Users will be most likely be using other tools such as the **Unified Listing** or **Preference tools** to look at or even suggest new settings.

Using the PTD

The PTD is accessed at

This introductory video webcast supports the detailed text documentation.

Contributing to the PTD

Open Questions

Should a batch editing feature be added?

Either in the UI or via CSV import? UI row based data entry can be fast. If contributors are to use forms these could be google docs which export as CSV

Would direct import from solution settings be useful?

I have been thinking of writing a tool that, when given an Android APK or URL, installs the app on an emulator, and then picks through the app's shared preferences as stored on disk. It would compare the application information to what we have in the Unified Listing, and let us know if this appears to be a new "solution". It would also identify any preferences we are not already aware of in the Preference Terms Dictionary.

In that scenario, a contributor only really needs to make us aware of the app, by sending us a URL or uploading an APK. We can then automatically prepare candidate data for the UL and PTD moderators to review. This to me is a more inclusive way to gather the data, and focuses people's time where it's most useful, on review tasks and decision making.

Would need to easily eliminate irrelevant settings.