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
