Hi all, I'm sorry for replying to myself but I've started a confluence doc [1] where I'm tracking all VIVO integration requirements and a possible specification. It would be really useful if people could have a look at it and make sure that I'm on the right track here. (I've made some assumptions that might not be properly aligned with the goals for this integration)
I'll be tracking most of the work I'm doing in JIRA against KERN-3081 [2]. Simon [1] https://confluence.sakaiproject.org/display/KERNDOC/KERN-3084+VIVO+Integration [2] https://jira.sakaiproject.org/browse/KERN-3081 On 7 Aug 2012, at 10:11, Simon Gaeremynck <[email protected]> wrote: > I found some code at [1] which seems to proxy the data via a custom servlet. > It follows the same retrieval method as I'm using right now (ie GET the > /individual/id.rdf and converting it to JSON). It then spits out JSON similar > as to how the UI gets it's JSON from the current authprofiles. It's nice > work, but I don't think it's very sustainable? > > Simon > > > [1] > https://github.com/liyushan/sparsemapcontent/commit/e6795f92d869c9b629bbd0da54b11ce09adf886d > > > On 7 Aug 2012, at 09:45, Simon Gaeremynck <[email protected]> wrote: > >> Hi John, >> >> I've been working under the assumption that VIVO would become an integral >> part of a deployment and would handle all related profile storage and that >> there would be an option to have 'simple' profiles. If we are going down >> that route I don't think that the existing profile service will cover all >> use cases. But I wanted to check on-list to make sure. >> >> I know that some work has been done by writing Freemarker templates in VIVO >> which return JSON, but I haven't been able to track this work down? >> >> Simon >> >> On 7 Aug 2012, at 07:40, John Norman <[email protected]> wrote: >> >>> There is an important architectural principle that needs to be established. >>> Will Sakai run without Vivo? IIRC the profile design work previously >>> assumed that the answer to this must be 'Yes' and Vivo would just be an >>> optional data source. For me the interesting model would be to invert the >>> logic and make the answer 'No'. There might be a minimal profile service >>> bundle that could come with Sakai code, but full functionality would depend >>> on a Vivo installation. We would need to anticipate that institutional >>> deployments of Vivo might pre-exist Sakai and have been customised in our >>> architectural model. I think this is how identity management is handled in >>> some Kuali apps - Kuali Identity Management as a very basic module for >>> testing, but an assumption of integration with a full identity management >>> system for real installations. >>> >>> I believe there is work on permissions within the Vivo community, but I >>> have discussed it recently. >>> >>> Did you find Yushan's work on a profile widget pulling information out of >>> Vivo? >>> >>> HTH >>> John >>> >>> On 6 Aug 2012, at 22:24, Simon Gaeremynck <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I'm working on trying to use VIVO [1] as a possible repo to host all our >>>> profile information on. I've been going trough confluence and the >>>> user/profile bundles to determine how it might tie into Sakai and I'm >>>> slightly questioning if the existing codebase would be sufficient to cover >>>> what we need. >>>> >>>> Afaict, the (current) way to go is by using KERN-739 [2] which was created >>>> to handle this kind of thing. You can express external data-feeds by >>>> setting the 'sakai:source' property on the authprofile node (or any child >>>> thereof) to external. When you do a request to >>>> ~/simong/public/authprofile.profile.json, it will then trigger your >>>> ProfileProvider implementation which can deal with getting the data from >>>> the external source. This would also require a >>>> LiteAuthorizablePostProcessor who creates that property upon user creation. >>>> >>>> I've tried this approach and it does work (ie: I'm able to grab external >>>> data out of VIVO and bring it into sakai) but I'm wondering if this would >>>> be the way to go forward. It doesn't look like it was ever meant to handle >>>> full profiles but rather parts of a profile. ex: only publications are >>>> external. >>>> I've talked to Ray who has written the persondirectory contrib bundle >>>> which does a similar thing and he seems to be hesitant to use this kind of >>>> logic as it has never been really used (as far as we can tell). >>>> >>>> Some factors that might play a role into all of this are: >>>> - The ability to ACL certain profile data, this is something that VIVO >>>> doesn't provide (again: afaict) and certainly isn't trivial. >>>> - The ability to update profile information from within sakai. This might >>>> need a custom ProfileService impl ? >>>> >>>> Has anyone ever done anything like this or has some advice/ideas on what >>>> the best approach would be? >>>> >>>> I'll be tracking my work against KERN-3081 [3] if anyone is interested. >>>> >>>> Thanks, >>>> >>>> Simon >>>> >>>> >>>> >>>> [1] http://vivoweb.org >>>> [2] >>>> https://confluence.sakaiproject.org/display/KERNDOC/KERN-739+Dynamic+user+profiles >>>> [3] https://jira.sakaiproject.org/browse/KERN-3081 >>>> _______________________________________________ >>>> oae-dev mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> John Norman >>> Director - CARET >>> University of Cambridge >>> [email protected] >>> +44-1223-765367 >>> >> > _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
