Tue July 31, 12:00-14:00 UTC Translate to my time zone NoticeThis meeting is being held as part of the Raising the Floor Consortium. The Raising the Floor membership agreement, in particular its IPR policy, applies to the contents of the meeting. AttendanceUpdates (including user groups involvement)- Gottfried, Christophe, Andreas (HdM)
- Andres (TECH)
- Andy (Axelrod)
- Claudia, Gerhard (TUD)
- Colin (IDRC)
- Jim (Inclusive Tech.)
- Liddy (Sunrise)
- Vassilis (CERTH)
- Ignacio
- Xavier
Securing our discussions and decisionsFormat of preferences setSummary of results: Pages of past discussions: Summary: Discussion: - Format of condition?
- Proposal too preliminary? Derive a new proposal based on new user research? Involve user interaction team of IDRC?
- "Semantic presentation" - User should be able to edit conditions.
- But: Should we constrain the condition language just for the authoring tool? But there may be other tools and automatic generation of conditions that don't have these constraints.
- Need to register terms that are meaningful to the user for describing context and context items.
- Do we need all these operators?
- Most users will not edit their preference sets, they will just adjust their settings in different contexts.
- Do we need labelled sets of conditions? - Extension of current proposal.
- If adaptations are dependent on conditions, how are users going to correct them? - User feedback loop. Hard to do with current syntax.
- Preference values can depend on other pref. values. Also depend on context item values. Implement something now and then validate this.
- We need decisions to migrate preferences from one platform to the other, and from one application to another.
- Decision: Let's not term the current proposal as "final", but as "first proposal". Let implementors use this first proposal if they want to - baring the risk of having to change it later. Try to keep it as simple as possible.
- Canonical form of a preference set?
- Architecture board agreed on using JSON as standard representation. Preference server will be able to deliver preference sets in the standard format, though other formats may be delivered as well.
- We should say that the preference server will have supported formats to serve information. "Default presentation"?
- Terms can be releated through an external registry. Or they can be related via conditions.
Digital Resource DescriptionIssues from last meeting: - Do we need a vocabulary for resource description?
- If yes, do we want to reuse ISO/IEC 24751-3 (which used a simple 1:1-relationship approach)?
- Can we build matchmakers that can deal with resources without artifical resource descriptions?
- Can we use schema.org, attributes, and HTML markup to automatically derive metadata on resources? - Currently being explored by IDRC, Andy and others.
We should make metadata as simple and directly attached to resources as possible. (This item was not discussed due to time constraints.) Action Items- Look at existing ISO standards that use a registry approach. (See topic 43.)
- Formulate proposals for dealing with conditions (see topic 34).
- Jutta: share a preliminary list of needs & preferences for literacy users.
Future Meetings- Tue Aug. 14, 12:00 UTC = 2pm CET (Gregg chair)
- Tue Sep. 4, 12:00 UTC = 2pm CET
Future Agenda Items- Presentation on user ontology
- User research with user interaction teams.
|