Discussion on Profile Structure

Owned by Gottfried Zimmermann
Last updated: Aug 14, 2012 by Gregg VanderheidenVersion comment
2 min read

Discussion on User Needs&Preferences Set Structure

Technical goals (see [Goals of New Version of Standard|display/ISO24751/Goals+of+New+Version+of+Standard]):

  • Allow for continuous updating of needs and preference terms
  • Define a process for maintaining a core set of needs and preference terms.  [YET TO DO]** Define a process for adding Additional core and other terms** Define a process for adding (non-core) device/application specific properties 
  • Allow for inclusion of CONDITIONS  - though we need to figure out what all the ways or meanings of context are.  Is it a continuum or are there different types of CONDITION?   
    • Part of the product that the preference applies to  (e.g.  font size for text, or headers, or footnotes, or captions or....)
    • Device/Platform  (Properties may apply to a specific user interface platform or be generic (cross-platform)
    • User situation 
    • "All the properties that determine the specific setting that should be used."
      • time of day
      • fatigue level
      • physical environment
      • part of the product the setting will be applied to
      • person you are interacting with   
  • Allow for generic and individualized profiles to be used for user interface and digital resource adaptation 
  • Ability to have generic and very individualized contexts
  • CONDITION-sensitive and non-CONDITION-sensitive preferences - 
  • Users should have an easy way of modifying their profile, and should not be required to understand the raw profile  [OUT OF SCOPE OF STANDARD TO PROVIDE. ONLY DUTY IS TO NOT PREVENT]

"CONDITION"

  1. Purpose of CONDITION
    1.  for indicating when a particular item in theUser Needs&Preferences Set should be applied
    2.  (or for switching to a different one?)
  2. Possible Types of Conditions
    1. device (that is being adapted)   
    2. Phone vs computer)
    3. contextually responsive  
    4. environmental 
    5. *(see http://wiki.gpii.net/index.php/REGISTRY)*
    6. User specific Conditions for switching profiles  (when I am in my AMIGO vs when I am at my desk)  

Proposed key points for discussion:

#

Key Points

Agreed

1

The REGISTRY of user preferences TERMS consists of Name-ValuesSpace-Definition etc in a flat structure. (Basically a dictionary of = TERMS to be used ) (There is a COMMON REGISTRY maintained for ISO by Raising the Floor - International.  But anyone can create and maintain another registry as well - usually to supplement the COMMON REGISTRY)

2

User preferences (an item in the User N&P Set) consists of PropertyID-[condition (ConditionIDs and ConditionValues]-PropertyValue triplets in a flat structure.


3

Are the user N&P preferences sets themselves all flat or are they layered?    FLAT right?  (Discussion)

 

4

PropertyIDs and ConditionIDs in the PCV Triplet are URIs pointing to a term in a registry  (the COMMON REGISTRY or another.) 

The ValueSpace for the values (for both Properties and Conditions) are defined by the TERM definition in the REGISTRY (COMMON REGISTRY or other registry) located at the URI. (Discussion)

4

Should we have URLs rather than the more general URI? (Discussion)

 

5

There are two categories in the registry: core and non-core. (Discussion)

6

There is a COMMON REGISTRY and APPLICATION SPECIFIC REGISTRIES 

  • the AS Registries contain terms that would ONLY make sense to a particular application.  
  • the AS Registries are maintained by the Application developer/maintainer
  • the COMMON REGISTRY is maintained by RtF-Int'l for ISO
  • there can be OTHER registries as well and they will work

 

7

The items in the Registry are called TERMS  (Property TERMS, condition TERMS etc)

 

8

Items that are duplicates are handled using the ALIAS feature in the registry where the preferred term Is pointed to from the duplicate (or old ) term.

 

9

 

 

10

 

 

11

 

 

12

 

 

13

In a user preference profile instance, each entry (property-value pair) may have a probability assigned.  The default value is 1 (100%).  Another feature where probability is involved is "partially needs to meet", "completely needs to meet" (see 24751).  How well the resource meets a particular user need.  But that's related to DRD.     [NOT PART OF STANDARD????]

 

14

Where other standards provide useful key definitions, can we import them by using their domain as part of the key URI?  [HOW EXACTLY??  just in definitions/note section?  if they are not in std Registry format  can they be used directly?  ] (Discussion)

 

15

 

 

16

The definitions in the OLD 24751 need to be reviewed before becoming CORE

 

17

Items in the COMMON REGISTRY that have been provided by vendors, user groups, other standards groups, or any third parties start off as NON-CORE items (Discussion)

 

18

Both core and non-core properties stored in the registry database in the same format. the CORE terms just have "isCore" flag set?

 

19

The COMMON TERMS database will be hosted for ISO by Raising the Floor under reg.gpii.net

 

20

A web-based interface should be provided to allow access to the COMMON REGISTRY by the public

 

21

Part of new ISO/IEC 24751 defines the data model for the registry.

 

22

Part of new ISO/EIC 24751 should define the policies for adopting core and non-core properties into the registry

 

23

The COMMON REGISTRY will not have any hierarchical ontology itself but will support the use of multiple external ontologies with the REGISTRY to make it easy to view the TERMS through Ontologies. (e.g. as RDF/OWL files on a Web server)

 

24

 

 

25

What is our preferred practice for finding or adding preferences? (Discussion)

 

26

How do we represent different settings/variations for different contexts (e.g. times, ambient light, locations? (Discussion)

 

 

IN USE the preferred practice is:

  1. use a common preference (core or non-core) if one exists that fits
    1.  if none applicable - then ADD a new live preference
  2. for application-specific settings (e.g. location of the toolbar on top or left of xyz view in qrs application) use a vendor or product specific namespace.  
  3. only where necessary use a data block to store preferences  (and this would be in a application-specific namespace
  4. NOTE: reg.gpii.net will provide space for people / organizations to maintain vendor or product specific namespaces.  This will be especially useful for open-source product but can be used by any vendor that does not want to maintain their own preference server.

 

Discussion

  1.  
  2. [OPEN] Are the user N&P Sets themselves all flat -- or are they layered????#* Some scenarios may require a more complex structure.  Example: "Visual content requires text alternatives".  Can be flattened by multiplying out the subject or both subject and object. "visual-content-requires: text" or "visual-content-requires-text: true".  Better: "Text-alternative-for-visual-content: true".
    • Pragmatic approach, no semantic parsing required.
    • This is not meant to be exposed to the end user.
    • Goal to make this most shareable/interoperable as possible.
    • Should not have complex structures - we need simple structures that could be combined to express complex things
    • Still need to consider Semantic Web concepts if they are applicable to our case.  RDF and tool support.  Erlend will post some information on the Wiki.  But how much of this has been accepted in the user profile area?  Need to get vendor support.
    • Two sides of the coin: User preference profile = simple structure of property-value pairs; user model = can be sophisticated ontology/structure expressing relationships etc 
  1. Unknown macro: {WHAT does this mean????}

    [AGREED] In a user preference profile instance, the value of those keys that are not present, are unknown (incomplete profile).    

      • [GV] Not present where?   at the URI?   
      • [LN] If we do not require properties to have values, we don't need to worry about incomplete profile sets...
    2. {*}
    {*} 
    [AGREED]     In a user preference profile instance, one key may occur multiple times, but only with different values.    
    • [GV] What does this mean?  in a registry or a preference profile?   which should be used? 
    • [LN] In the registry, each property should be defined as a pair etc but the same property may have two values eg language property might have both English and Readability Level 2 as values so it would occur twice (depending on what values are expected for 'language' of course).
  2. {WHAT does this mean????   is this now a CONDITION} 
    [OPEN] In a user preference profile instance, some keys may have a language tag attached to their value for disambiguation in case of multiple occurrences in a profile.   ## [GV] What does this mean? 
  3. #* Like a second key layer (but not used as official key).
    • Other use cases?  E.g. home vs. office phone number? - But you can accommodate for that by using different property names.
    • [LN] Suppose there is an English description of an article and also a French description, or there are two authors and their email addresses need to be associated with the correct name, ...
  4.  
  5. [OPEN] Where other standards provide useful key definitions, we can import them by using their domain as part of the key URI (e.g. "http://purl.org/dc/elements/1.1/title").
    • [GV] (this is always allowed but is it a good idea for stability?  Should this be an option (it  always is) or recommended.   (If borrowed then we should credit in the description)  
    • [LN] Do you mean  import them as  core terms or something or do you mean include them in a record? After working with such things for a while in DCMI, both the ed group and the accessibility group have recommended having atheir properties as modules of properties to be used with others - leaving other properties where they are ...
    • GZ: Agree. Just including as records.

Proposed Definitions">Proposed Definitions

COMMON - These are preferences that are generic in nature and would be used by multiple applications.  They are intended to be defined and used in common between applications.  (They would stored in the MAIN REGISTRY)
 
There are two types of COMMON preferences

CORE (COMMON):  These are COMMON preferences that have been studied and are believed to be stable and fixed.  A committee will review the LIVE COMMON (or LIVE) preferences and determine when they should become CORE COMMON (or CORE).   In tagging them with CORE designation, the name or definition or value range might be tweaked but care must be take to not break any use of the tag by existing user preference profiles. 

LIVE (COMMON):  These are COMMON preferences that have been entered by someone because there was not already another COMMON preference that met the need.  Anyone can submit a new preference to this set and it will be included unless it is an obvious duplication.    All LIVE preferences are candidates to become CORE.

These two categories of COMMON preferences would be maintained in the MAIN REGISTRY.

APPLICATION SPECIFIC - These are settings that would never be candidates for a COMMON preference because they are so specific to an application that they would not make sense as a COMMON preference.    An example may be whether a particular toolbar in an application is located above or below another toolbar in the application or off to the left.    

APPLICATION SPECIFIC preferences are maintained by whomever is maintaining the application -- and would not be in the MAIN REGISTRY.    (Preferences always include a pointer to which registry they are defined in)

USER PROFILE MODEL - The structure of a user preference profile.

USER PROFILE INSTANCE - A user preference profile with data for a specific person or group of persons.

See Also

See also:

OLD PAGE BEFORE CLEANUP