[Accessforall] Notes from the PNP meeting
Gottfried Zimmermann (List)
zimmermann at accesstechnologiesgroup.com
Tue Jun 5 16:59:08 UTC 2012
The notes are posted at
http://wiki.fluidproject.org/display/ISO24751/2012-06-05+Meeting and below
The next meeting will be next Tue June 12, at the same time (12 UTC).
Thanks for a good meeting,
Prof. Mobile User Interaction
Hochschule der Medien, Stuttgart, Germany
Phone: +49 711 8923-2751
Email: <mailto:gzimmermann at hdm-stuttgart.de> gzimmermann at hdm-stuttgart.de
Tue June 5, 12:00-14:00 UTC
2&hour=12&min=00&sec=0&p1=0> Translate to my time zone
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.
* Andy (Axelrod...)
* James, Jutta (IDRC)
* Liddy (Sunrise)
* Vivien (FHG)
* Andreas, Christophe, Gottfried (HDM)
* Andrea (SDC)
* Thomas, Vassilis(CERTH)
* Gregg (RtF-I)
Updates (including user groups involvement)
Editors had 3 meetings. Liddy has made a personal draft at the Wiki,
First draft (24751-1 Framework) is due in mid-June, to be submitted to SC36
in due time for voting within the September meeting of SC36. There will be
another editors meeting, probably this week.
Discussion on Profile Structure
Refer to <http://wiki.gpii.net/index.php/Discussion_on_Profile_Structure>
HdM's proposal: <http://wiki.gpii.net/index.php/HDM_Glossary_Proposals>
Personal Needs and Preferences (PNP) Profile
A PNP profile is a flat list of user Preferences. A Preference consists of a
* Property, which serves as a link to the registry to obtain the
definition of the Property. For example "FontSize".
* Value, which states the value the user wants for the given Property.
The Value conforms to the Property definition.
* "Über-Condition", which specifies in which circumstances the Value
The user profile contains ONLY preferences set or verified by the user.
Preferences which were inferred by a MatchMaker are not stored in the user
profile, as they are MatchMaker specific and using multiple MatchMakers at
once would cause problems. If a user verifies and confirms an inferred
preference through any means, it may be added to the user profile.
A preference server may support keeping track of old values in a PNP
profile. This might be useful for some matchmaking tools.
"Über-Condition" is expressed as a Boolean expression. If it evaluates to
"true", the preference applies. If it evaluates to "false", or if there is
insufficient information available to evaluate the condition, or if an error
occurs, the preference does not apply.
Preferences can occur in different formats in a system (e.g. in a preference
server, on a client, etc.). Conditions are a way of expressing a set of
preferences each for a different situation. A "resolved profile" with
"resolved preferences" does not contain conditions, because it has been
applied to a specific situation (i.e. the conditions are resolved based on
the situation). A "partially resolved" profile has some conditions resolved,
but not all.
There might be situations where the conditions of multiple preferences with
the same property evaluate to true. In this case, the order of the
preferences in the profile is significant. The first/last?? preference wins.
Note that the order of preferences is independent from their date/time of
* Look at existing ISO standards that use a registry approach. (See
* Formulate proposals for dealing with conditions (see
* Jutta: share a preliminary list of needs & preferences for literacy
Tue Jun 12, 12:00-14:00 UTC
Future Agenda Items
Appendix A: Metadata Resources
* Email message by Andy on 2012-02-07.
* Schema.org: http://schema.org/
* NSDL Paradata standard:
* Link to Paradata learning registry:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Accessforall