Attendance

Gregg Vanderheiden
Andy Heath
Erlend Overby
Gottfried
Liddy Neville
Jutta Treviranus
Vassilis Koutkias

Action Items

Note: These action items are from our meeting on 2012-01-17. The minutes of 2012-01-24 have not come around.

[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

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.
1. 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".
2. Pragmatic approach, no semantic parsing required.
3. This is not meant to be exposed to the end user.
4. Goal to make this most shareable/interoperable as possible.
5. Should not have complex structures - we need simple structures that could be combined to express complex things
Keys are URIs, values are of any type that can be stored as a string.
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 occurences 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).

Housekeeping

We will be using GoToMeeting for now until we decide otherwise. The connection information is posted on the ISO 24751 Wiki starting page.

Adjournment

at 20:00 UTC

Browser not supported