[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31
Gottfried Zimmermann (List)
zimmermann at accesstechnologiesgroup.com
Tue Jan 31 20:07:45 UTC 2012
The minutes are posted at http://wiki.fluidproject.org/display/ISO24751/2012-01-31+Meeting and below my signature.
Thanks for your participation in a very good meeting. We will continue our discussion on profile structure in our next meeting on Tuesday Feb. 7 at the regular time.
Prof. Dr. Gottfried Zimmermann
Access Technologies Group, Germany
* 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.
1. [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.
2. [GREGG V] To get a contact with Deaf - Blindness
1. Talked with Amy Parker, she is interested and willing to contribute
3. [Jutta ]: will hold a 1-2 hour consultation with all of the Bianca Stern Andrew Arch and David Sloan
1. Will happen this week
4. 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 <http://wiki.fluidproject.org/display/ISO24751/Recruiting+Input+Regarding+Needs+and+Preferences> 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
* Liddy's Thoughts on New Work <http://wiki.fluidproject.org/display/ISO24751/Thoughts+on+New+Work>
* Gottfried's <http://wiki.fluidproject.org/display/ISO24751/Statements+for+user+profile+standard+development+%28for+discussion%29> Statements for user profile standard development (for discussion)
Technical goals (see <http://wiki.fluidproject.org/display/ISO24751/Goals+of+New+Version+of+Standard> 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:
1. A user profile consists of property-value pairs in a flat structure.
a. 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".
b. Pragmatic approach, no semantic parsing required.
c. This is not meant to be exposed to the end user.
d. Goal to make this most shareable/interoperable as possible.
e. Should not have complex structures - we need simple structures that could be combined to express complex things
2. Keys are URIs, values are of any type that can be stored as a string.
3. 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/> http://myurc.org/TR/res-prop-vocab1.0/ as an example.)
4. In a user profile, the value of those keys that are not present, are unknown (incomplete profile).
5. In a user profile, one key may occur multiple times, but only with different values.
6. Some keys may have a language tag attached to their value for disambiguation in case of multiple occurences in a profile.
7. 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").
8. 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).
9. The "core properties" are key definitions that have been accepted by ISO 24751.
10. The "live properties" are key definitions that have been provided by vendors, user groups, other standards groups, or any third parties.
11. Both core properties and live properties are stored in a registry database.
12. The registry database is hosted by Raising the Floor.
13. A Web-based interface provides access to the registry for the public.
14. A part of ISO/IEC 24751 defines the data model of the registry.
15. A part of ISO/EIC 24751 defines the process of adopting core and live properties into the registry on a regular basis.
16. "Views" may be specified on top of the key-value pairs, each defining a particular structure/ontology for the key-value pairs.
17. 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.
* at 20:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Accessforall