[Accessforall] Notes from the PNP meeting

Gregg Vanderheiden gv at trace.wisc.edu
Tue Jun 12 23:03:05 UTC 2012



On Jun 12, 2012, at 6:53 AM, Christophe Strobbe wrote:

> Dear Liddy,
> 
> Thanks for sharing this draft. I have a few questions and comments:
> 
> (1) In the telecons so far, people involved in the Cloud4All project have focused mostly on (UI) adaptation, and this has driven many proposals and decisions. But the revised ISO/IEC 24751 should also cover the matching between user needs/preferences and resources (i.e. resources that don't necessarily adapt themselves). Do you think that the latter goal is insufficiently covered by the proposals and decisions so far, or that some of these are suboptimal (or worse) for this objective?

Good question.  I have been watching out for this and I think structurally we are good.    And as to preferences -- we really aren't doing those specifically - but rather looking at COMMON TERMS that would be used for UI and resources (adapting or not). 

But it is good to watch out for this since our implementations are all UI. 



> 
> (2) The first sentence reads: "ISO/IEC 24751 is intended to facilitate the matching of individual user needs and preferences with digital resources that meet those needs and preferences." I would appreciate it if the concept of adaptation/adaptability could be included in this sentence. (When reading the draft for the first time, the current wording gave me the impression that adaptability was downplayed compared to providing matching resources; I had to reread it to see that this was not the case and that the first sentenced had "primed" my mind in that direction.)

Actually I would like to see UI also added.  digital resources doesn’t seem to describe built in access features or flexibilities in a product.  

Maybe change it to 


 "ISO/IEC 24751 is intended to facilitate the matching of individual user needs and preferences with digital resources and UI adaptations that meet those needs and preferences."


> 
> (3) In the proposed structure, parts 2 and 3 are about the registry/registries. Where will topics such as conditions and matching (including conflicts) be covered?

The registries are for COMMON TERMS used in the defining user needs and preferences -- which in turn consist of properties and conditions.  The COMMON TERMS would be used in both the properties and conditions sections of a user preference. 


> 
> (4) Should the definition of "matchmaker service" also take into account that context parameters such as location, ambient light and ambient noise (in addition to time) may also be taken into account?

Good idea.  We should make sure that the definition is also open ended (not a list definition) so that it includes things 'such as' or 'including but not limited to'  because the matchmakers in the future may take many more things into account. 

Gregg



> 
> Best regards,
> 
> Christophe
> 
> From: Liddy Nevile <liddy at sunriseresearch.org>
> To: Gottfried Zimmermann (HdM) <gzimmermann at hdm-stuttgart.de> 
> Cc: "Accessforall at fluidproject. org" <Accessforall at fluidproject.org>; SP1 at cloud4all.info; SP2 at cloud4all.info 
> Sent: Wednesday, 6 June 2012, 1:44
> Subject: Re: [Accessforall] Notes from the PNP meeting
> 
> Please note that I have attempted to include the decisions from last night's meeting in the ISO draft I have been working on at http://wiki.fluidproject.org/display/ISO24751/New+Version+of+24751+Part+1
> 
> 
> Liddy
> 
> 
> On 06/06/2012, at 12:08 AM, Gottfried Zimmermann (HdM) wrote:
> 
> > The notes are posted at http://wiki.fluidproject.org/display/ISO24751/2012-06-05+Meeting and below my signature.
> > 
> > The next meeting will be next Tue June 12, at the same time (12 UTC).
> > 
> > Thanks for a good meeting,
> > Gottfried
> > 
> > ____________________________________________________________
> > 
> >  Gottfried Zimmermann
> >  Prof. Mobile User Interaction
> > Hochschule der Medien, Stuttgart, Germany
> > Phone: +49 711 8923-2751
> >  Email: gzimmermann at hdm-stuttgart.de
> > Web: http://www.hdm-stuttgart.de/home/gzimmermann
> > ____________________________________________________________
> > 
> > 2012-06-05 Meeting
> > Tue June 5, 12:00-14:00 UTC
> > 
> > Translate to my time zone
> > 
> > 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
> >     • 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,http://wiki.fluidproject.org/display/ISO24751/New+Version+of+24751+Part+1. 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 should apply.
> > Inferred Preferences
> > 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.
> > 
> > History
> > A preference server may support keeping track of old values in a PNP profile. This might be useful for some matchmaking tools.
> > 
> > "Über-Condition"
> > "Ü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.
> > 
> > Conflicts
> > 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 creation.
> > 
> > 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 Jun 12, 12:00-14:00 UTC
> > 
> > Future Agenda Items
> > 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/
> > 
> > _______________________________________________
> > Accessforall mailing list
> > Accessforall at fluidproject.org
> > http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
> 
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
> 
> 
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120612/13c9020c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120612/13c9020c/attachment-0001.bin>


More information about the Accessforall mailing list