(Profile, Preferences, Account) UCamp Update

[Michael Feldstein]

The idea of kernel-level profile services is interesting and timely, 
given the IMS Enterprise Services integration work that is currently 
going on. IMS Enterprise Services v2 will have a reasonably rich Person 
model. (There will be a mapping to eduPerson, by the way.) It would be 
great if Sakai could consume and store all of this information, while 
still allowing for context-specific choice to be made regarding what 
gets displayed, whether certain global data can be replaced with context 
specific data (e.g., a course-specific email address), etc. By doing so, 
you could also have a central place to manage FERPA and other 
privacy-related policies.

- m

Ray Davis wrote:
> I've always been sorry that Sakai was unable to coordinate Indiana's 
> Profile needs with framework development plans. (At the very least, 
> supporting "EduPerson" attributes seems like a pretty basic LMS/CLE 
> requirement!) Making Profile a pseudo-standalone tool was probably 
> the only practical way for the team to deliver it in a timely 
> fashion, but for obvious reasons its services and data end up 
> bleeding into apparently separate tools (notably Roster). Similarly, 
> the functionality described by Vivie is hardly JForum specific, and 
> could be useful to many installations who prefer to deploy other 
> discussion software.
>
> Trying to figure out a single UI that will meet the vastly varying 
> detailed functional requirements of all our target users might be 
> overwhelming. But I do believe there's a general need for some 
> centrally managed store of person data that's more complex than our 
> current "User" module or "Preferences" tool support: behind the UI, 
> we need to allow for more efficiently handled properties and we need 
> to allow for more contexts (e.g., a course-specific email address for 
> instructors, or a project-specific username for language classes). 
> While the usability research continues, maybe some of the people 
> working on the user kernel services could begin to talk about ways of 
> handling this problem. It's possible that with services in place, a 
> suite of lighter-weight profile-style applications might be more 
> cheaply produced.
>
> Ray
>
> At 08:36 PM 11/16/2007, Vivie Sinou wrote:
> ...
>   
>> We use Jforum's My Profile which our users love
>> as it offers just in-time member data and opportunities for users to learn
>> about each other and connect while collaborating and communicating in
>> discussions.
>>
>> We eliminated Profile two years ago, as it was confusing to users to have
>> two profile tools. Jforum's My Profile is also global, reads Account data,
>> and offers great functionality to our users when they need it the most -
>> communicating and collaborating. Jforum's My Profile allows participants to
>> set preferences, avatars, IM info, interests, etc. We plan on expanding on
>> Jforum's My Profile functionality to provide opportunities for networking
>> and collaborating, based on profile interests.
>>     
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>   

-- 


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071119/96191c49/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071119/96191c49/attachment.gif>