HDM Glossary Proposals

From wiki.gpii
Jump to: navigation, search

This page is part of the work around AccessForAll / Needs and Preferences; see Needs and Preferences Working Group and Discussion on Profile Structure.

Personal Needs and Preferences (PNP) Profile

A PNP profile is a flat list of user Preferences. A Preference consists of a ...

  • Property, which serves as a link to the registry to obtain the definition of the Property. For example "FontSize".
  • Value, which states the value the user wants for the given Property. The Value conforms to the Property definition.
  • "Über-Condition", which specifies in which circumstances the Value should apply.

Inferred Preferences

The user profile contains ONLY preferences set or verified by the user. Preferences which were inferred by a MatchMaker are not stored in the user profile, 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 the user profile.

History

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

"Über-Condition"

"Über-Condition" is expressed as a Boolean expression. If it evaluates to "true", the preference applies. If it evaluates to "false", or if there is insufficient information available to evaluate the condition, or if an error occurs, the preference does not apply.

Preferences can occur in different formats in a system (e.g. in a preference server, on a client, etc.). Conditions are a way of expressing a set of preferences each for a different situation. A "resolved profile" with "resolved preferences" does not contain conditions, because it has been applied to a specific situation (i.e. the conditions are resolved based on the situation). A "partially resolved" profile has some conditions resolved, but not all.

Conflicts

There might be situations where the conditions of multiple preferences with the same property evaluate to true. In this case, the order of the preferences in the profile is significant. The first preference wins. Note that the order of preferences is independent from their date/time of creation.

Rationale:

  • Last - Latest update wins
  • First - Performance advantage, parser doesn't need to evaluate a second condition if it already has a first value.
  • First - Parser may not need to read the full file.
  • First - Partial matching for boolean expressions?

MatchMaker Infrastructure

Matchmaker db.png

  • Matchmaker storage is specific to matchmaker.
  • Ethical implications of a matchmaker storing inferred preferences.

MatchMaker Input

  • Current User Profile 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

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.

Device characteristics

Approaches:

  • Server-side: WURFL database (http://www.tera-wurfl.com/explore/index.php)
    • About 400 properties
    • Useful for legacy devices
  • Client-side: Dynamically sniff the device's characteristics
    • Best approach for future, most flexibility
    • Works for some features on a client/web browser

We should be able to pursue both approaches. Also, our architecture should support various types of device description ontologies, etc.

Do we need to define device, context, environment properties in a registry?

  • Needed by profile resolver.
  • Needed by editors of conditions.
  • We may need to reference parts of other standards (CSS Media Queries, JavaScript, WURFL, CC/PP, etc.)

Possible strategy:

  • For new devices:
    • Allow for feature detection on the client,
    • or supports WURFL or another publicly available database, or
    • supports the GPII device description database, or
    • manufacturer provides their own device description database.
  • For legacy devices: Tap into existing databases (WURFL, CC/PP, ...)

Notes

Conflicts and conditions:

  • If a conflict occurs within a user profile, the first property value wins. Note: Order of preferences in profile is significant.
  • Preferences in a user profile don't have a priority.
  • Preferences in a user profile don't have a probability. (Rationale: Probabilities depend on the algorithm that assigns them; if multiple "matchmakers", i.e. with different algorithms, work on the same user profiles, the might assign different probabilities.)
  • Do not store inferred properties in the preference server. (I.e. matchmakers need their own storage.)
  • The preference server may store the history of user profile modifications (timestamp, modifying party, old value, new value).
  • Modifying party is either a human expert, a maintenance program, or the user themselves.
  • A condition expresses the applicability of a preference regarding device-, platform- and environment/situation-specific variations.
  • Use WURFL for device description.
  • For other cases: Differentiation by property name vs. by condition: If it is a reasonably-sized closed set of variations with names that are known by the application before runtime, it is coded by different property names.  Otherwise, it is coded by conditions.  Example: Upper-case text vs. lower-case text: coded by property names.  Time of the day: coded by condition.

Registry and ontologies:

  • The GPII infrastructure must be able to work without any ontology.
  • The GPII infrastructure has one registry for the CORE properties.
  • The GPII infrastructure includes a schema describing the value spaces for the CORE properties.  The schema may be part of the CORE registry.
  • There might be multiple ontologies building on our registry.  Ontologies are 3rd-party contributions and their owners are solely responsible for maintaining them.
  • The registry must not point to any specific ontology.
  • A matchmaker may make use of a specific ontology.