Notice

This 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.

Attendance

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 decisions

Summary of results:

Glossary: http://wiki.gpii.net/index.php/Glossary

Pages of past discussions:

Overall Structure: http://wiki.gpii.net/index.php/Discussion_on_Profile_Structure
Context properties:
Device properties: http://wiki.gpii.net/index.php/Device_Profile
JSON format and coding alternatives: http://wiki.gpii.net/index.php/Simplifying_Preferences_Documents

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 Description

Issues 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.

Appendix A: Metadata Resources

Email message by Andy on 2012-02-07. http://lists.idrc.ocad.ca/pipermail/accessforall/2012-February/000034.html
Schema.org: http://schema.org/
NSDL Paradata standard: https://nsdlnetwork.org/stemexchange/paradata
Link to Paradata learning registry: http://www.learningregistry.org/

Bridge

1. To talk free using Web click. https://www3.gotomeeting.com/join/705233502
Be sure to set AUDIO to Mic and Speaker (VoIP) - a headset is recommended.

2. Or, call in using your telephone.

Meeting ID: 705-233-502

Australia: +61 (0) 7 3123 6029
Austria: +43 (0) 7 2088 1400
Belgium: +32 (0) 92 98 0592
Canada: +1 (416) 900-1165
Denmark: +45 (0) 69 91 88 62
Finland: +358 (0) 942 41 5778
France: +33 (0) 182 880 456
Germany: +49 (0) 898 7806 6461
Ireland: +353 (0) 14 845 976
Italy: +39 0 247 92 12 39
Netherlands: +31 (0) 208 080 379
New Zealand: +64 (0) 4 974 7215
Norway: +47 21 03 58 96
Spain: +34 911 82 9782
Sweden: +46 (0) 313 613 558
Switzerland: +41 (0) 225 3314 51
United Kingdom: +44 (0) 203 535 0621
United States: +1 (786) 358-5410
Access Code: 705-233-502

Browser not supported