Search the space:
I am not sure what people are thinking but here is a start from me (Liddy).
Here is a starting image to help us think about needs and preferences - the attribute headings are just illustrative, of course. Where there is 'context', it assumes that a person may have a number of different contexts. Any single person can add info to their context such as a name of it, and it could have location details, times, etc. .
In some other cases, people will think about other attributes of context such as the features of the device being used (esp technical attributes), the location of the device (for location specific resources), etc. Some of these things may turn out to be relevant to this work too. The abilities of devices, for example, should be relevant. Similarly, when 24752 is being worked on, the device being spoken to by the user may need to be considered - not sure but what about the maximum temperature at which a hot tap should deliver water?...
Currently ISO 24751 has many parts and each part deals with a particular type of resource, on the basis that each one introduces new types of problems - eg a digital object introduces different problems from a physical ATM (dealt with in 24752). I think that as a person has a profile of needs and preferences (N&P) they will want to use for some interaction, these could be described by N&P type and each part of 24751 could deal with a set of N&P types. For example, if Part 2 dealt with vision N&Ps, it could have ways of describing such N&Ps starting with the simpler and going into more and more detail. Then Part 3 could deal with auditory N&Ps, etc. Once the details are sorted for these parts, resources/interactions/devices/etc could be described in terms of those N&Ps.
Such a revision does raise the question of whether ISO 24751 should be two standards - one for N&Ps and one for descriptions - or if it should be set up in pairs as before - a part for N&Ps followed by a part for resource descriptions?
I have been wondering what the role of context is. We had a lot of difficulties fitting it into our original AccessForAll work with ISO despite many discussions. My problem was finding how to fit it into an RDF model. I was simultaneously concerned that the attributes we want should not be seen as attributes of a person, yet, they did have to share a common domain. I am thinking now that if what we are describing is a context, given its particularities, we can solve these problems. That is, if the 'domain' of our needs and preferences is a 'context', we can describe the accessibility attributes of that context, and say nothing about the many other attributes it might have - especially what gives cause to it.