Attendance

Gregg Vanderheiden
Andy Heath
Erlend Overby
Gottfried
Vassilis Koutkias
Colin Clark

Regrets:

Liddy Neville
Jutta Treviranus

Action Items

No new progress reported.

[ANDY] Recruit participant experts in Digital Literacy: (Andy will make a cold contact.)
1. Pending. Andy waiting for reply.
2. Jutta Croll has contacts too. Needs more details on what expertise is needed. Andy: Jutta & Jutta should talk about this. ECDL = European Computer Driving License.
3. Jutta T.: We want to capture all needs of users that we didn't capture in the first round (24751). By end of Feb. we want to have a comprehensive set of preferences.
4. Andy: What are we expecting from these experts, e.g. participation in calls, etc.? What process do we follow if they can't join the calls? Jutta: Ageing group will have a focused discussion, organized by Jutta T. Process specific to group.
5. Information: Andy has talked to DCL. Friend in discussion with Loughborough university, also in DCL. Should draw on the eLearning lists in the UK.
[GREGG V] To get a contact with Deaf - Blindness
1. Talked with Amy Parker, she is interested and willing to contribute
[Jutta ]: will hold a 1-2 hour consultation with all of the Bianca Stern Andrew Arch and David Sloan
1. Will happen this week
Jutta: Make a list of user groups involved, and those whose needs haven't been captured yet

Status Update: User (Experts) Involvement

No new progress reported.

Groups to be involved:

Ageing (Focused discussion organized by Jutta T.)
- Bay Crest: Number of scenarios developed, including context specific and function specific needs. New findings about needs that are currently not in 24751. Report will be sent to the general group soon.
- Andy will contact another person, Jutta T. will follow up.
Autism (Annuska)
LD, low vision, blindness: Gregg will get feedback from TextHelp. They are submitting their setting files.
Digital Literacy: nothing new.

For recruiting, see Recruiting Input Regarding Needs and Preferences\.

Liddy: We want to re-organize our needs and preferences, not by user groups.

Gregg: Tagging is good since it is not completely hierarchical.

Jutta T.: Found the same with ISO 24751.

Discussion on Profile Structure

Previous input:

Liddy's Thoughts on New Work\
Gottfried's Statements for user profile standard development (for discussion)\

Technical goals (see 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
Allow for ad-hoc needs and preference terms
Allow for inclusion of context and device related properties
Allow for generic and individualized profiles to be used for user interface and digital resource adaptation
Ability to have generic and very individualized contexts
Context-sensitive and non-context-sensitive preferences
Properties may apply to a specific user interface platform or be generic (cross-platform)
Users should have an easy way of modifying their profile, and should not be required to understand the raw profile.

Proposed key points for discussion:

A user profile consists of property-value pairs in a flat structure.
- 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 profile = simple structure of property-value pairs; user model = can be sophisticated ontology/structure expressing relationships etc.
Property names are URIs, values are of any type that can be stored as a string.
- Rationale: Link to semantic Web via URI, extensible system
- For matching algorithms there is only a flat set of properties.
- Registry Layers: Core, Live
- Unregistered properties can be used by any vendor (e.g. application-specific settings and data blocks).
- The API must pass both registered and unregistered properties. One API or multiple APIs?
- Core properties start with a defined domain name, e.g. http://gpii.org/ns/userprof. Live and vendor-specific properties have a proprietary domain name.
- Application-specific settings as block? E.g. all TextHelp settings in a bundle. “Virtual block” of many properties with common domain name, e.g. http://texthelp.com/ns/userprof. – This is about adaptation settings - different from properties in the user profile. But with a 1:1-matching, there could be counterparts of settings in a user profile.
- User profile storing expected behavior of applications only or describing persons? - Statistical methods don’t care.
- We need to get the big vendors on it. This is a way to achieve this. But what if the vendor doesn’t want to tell what their application can tweak (in terms of adaptation parameters)?
- What if a new technology comes along? Live space can host new properties, so that other know. Approval committee will look at properties in live part, and promote it to core (optionally renaming it) if appropriate.
- Culture is a context.
The definition of a key consists of its URI, and its type and value space (e.g. enumerated values, integer). (See http://myurc.org/TR/res-prop-vocab1.0/ as an example.)
In a user profile, the value of those keys that are not present, are unknown (incomplete profile).
In a user profile, one key may occur multiple times, but only with different values.
Some keys may have a language tag attached to their value for disambiguation in case of multiple occurrences in a profile.
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").
We will not develop key definitions related to device and usage context. However, we may import such keys from other standards (e.g. from OMA UAProf or W3C Delivery Context Ontology).
The "core properties" are key definitions that have been accepted by ISO 24751.
The "live properties" are key definitions that have been provided by vendors, user groups, other standards groups, or any third parties.
Both core properties and live properties are stored in a registry database.
The registry database is hosted by Raising the Floor.
A Web-based interface provides access to the registry for the public.
A part of ISO/IEC 24751 defines the data model of the registry.
A part of ISO/EIC 24751 defines the process of adopting core and live properties into the registry on a regular basis.
"Views" may be specified on top of the key-value pairs, each defining a particular structure/ontology for the key-value pairs.
Views are specified externally to the registry (e.g. as RDF/OWL files on a Web server).

Future Agenda Items

Metadata: See email message by Andy on 2012-02-07. http://lists.idrc.ocad.ca/pipermail/accessforall/2012-February/000034.html
One API or two APIs for the match maker?
Simple 1-to-1 relation between user profile properties and adaptation parameters?

Adjournment

at 20:00 UTC

Browser not supported