- What if we want to accommodate new interaction techniques that require new preference items? For example, consider the introduction of sign language output by avatars. We would need a new preference item for the speed of the sign language performance, for the preferred avatar, etc. Or for gesture-based input we would need additional preference items that specify a gesture alphabet.
- We need to define a framework that sets the structure of a user profile independent of its vocabulary items.
- The vocabulary (preference items) should be repository-based so that it can be updated on a regular basis.
- The framework (without vocabulary) should be defined in an ISO standard. Also, a process of approval for new vocabulary items for the repository should be specified in a second ISO standard.
- For an efficient development process, properties, structure and approval process can be developed in parallel.
I agree with the need for an extensible set of needs and prefs (n&p). This suggests to me that the structure of the list will be very important. This is why I have always argued for a model that starts with a gross category and then refines it. This means that where systems do not actually have implementations that use the new items, they will at least know where they fit. I recommend the approach we have taken for the ISO Metadata for Learning Resources (MLR) determination of classes etc and use maps that conect n&ps so from the beginning we know what is a refinement of what. That will make it easier in the long run to provide an extensible set.
The second point is that I think when you say repository, Gottfried, we could ask Mitsuharu Nagamori for a version of the schema registry that the Dublin Core community uses. Mitsuharu is familiar with these problems and the registry is already built and tested ....
The third point is that ISO does not work through registries, as I understand - so perhaps we have to think how to do this for the ISO standard. I am proposing an appendix to the MLR that will link the definitions there to the DC terms registry. This may be one way to do it?
A flat set of properties (key-value pairs) is most appropriate for practical reasons.
- In most cases, hierarchical constructs of user properties can be approximated by a flat set of properties with URIs as keys.
- See as an example the WURFL properties database for mobile devices. This simple collection of key-value pairs for thousands of mobile devices is a de-facto standard in industry today for the user interface adaptation based on mobile device characteristics. WURFL is regularly updated by a community. http://wurfl.sourceforge.net/
- Many standards in this area have a flat structure, and some use URIs as keys (e.g. Dublin Core, ETSI ES 202 746). This is a pragmatic approach, and allows for core properties and extension properties based on domain names. Also, using URIs as keys allows for formal definition of preference items (and constraints) in RDF. Note that doesn't mean that the preference values need to be coded in RDF.
- The core items will have a commonly defined domain name (namespace) as part of their URI. Third parties such as user groups and vendors can define their own extension items by using a different domain (namespace).
In general, the user properties stored in a user profile should be based on requirements rather than functional descriptions of the user. However, functional descriptions may help to efficiently derive requirements-based properties for the initialization or fine-tuning of user profiles.