- Gregg Vanderheiden
- Andy Heath
- Erlend Overby
- Liddy Neville
- Jutta Treviranus
- Vassilis Koutkias
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.)
- Pending. Andy waiting for reply.
- 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.
- 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.
- 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.
- 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
- 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
- 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
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
- 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).
- We will be using GoToMeeting for now until we decide otherwise. The connection information is posted on the ISO 24751 Wiki starting page.