[Accessforall] Needs & Preferences call today at 12:00 UTC

Gregg Vanderheiden gv at trace.wisc.edu
Tue Jun 12 22:48:14 UTC 2012

I think that the current architecture can easily support this kind of analysis and use case.  BUT it would depend on getting through the GPII ethics committee for use of User Preference Data.   I THINK that it would be fine.    I am promoting the idea that no user specific date mining etc be allowed. But that aggregate information that meets certain tests for preserving anonymity be allowed.  This I think would pass as long as we have enough users and data. 

On 12/06/2012, at 9:31 PM, Matthew Atkinson wrote:

>> 2. Stepping back, there seems to be a use-case for the match maker architecture that I am not sure is yet supported...
>> Imagine you want to aggregate users' data (anonymously of course) so that it would be possible to, e.g., say "Users on this OS and using this application tended to like the following GPII preferences." I think this could be very helpful in bootstrapping people and solving a key problem:
>>   People are often not aware of, or are able to discover, adaptations that could help them.
>> The work of the likes of David Sloan and Peter Gregor at Dundee, as well as many others at other institutions, shows this up as a key issue.  People sometimes assume that ICTs are not as flexible as they are, because they are used to inflexible real-world analogues.  Or perhaps they are too focussed on what they are doing and instead attempt to "muddle through" rather than search for means (GPII preferences, micro-ATs or classic ATs) that may help them in their task.
>> Therefore my question is: would the current architecture (as per the wiki) support such central/federated storage of user data and therefore aggregating it in order to make such suggestions, or is this something you are going to move on to specifying, or is it perhaps simply out of scope at this point?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120612/b5b5298b/attachment.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/b5b5298b/attachment.bin>

More information about the Accessforall mailing list