Hi Simon, Thanks so much for your initial investigation work and writing this all up. I'm sure it's the start of a very useful and fruitful integration.
I will forward some of these questions to the URG and TRG, so we can continue to collect the necessary feedback. I've got some minor comments inline as well. > 2. Search > I'm able to to search trough VIVO's data by querying their Solr > server (it's fairly trivial to run this in the same cluster as OAE > is running, it's not required though). None of that is ACL'ed though > and AFAICT there is no such thing as a Permission scheme in VIVO > (yet.) Doing this on our side won't be trivial and will require some > substantial work. How hard is it going to be to merge the VIVO and Sakai search results so we can get a single list of results that includes all of the Sakai OAE data we need? This will need confirmation by the URG, but I'm afraid that not offering a Permission Scheme for profile section might be an issue. It's definitely worth investigating how much effort would be involved in making Sakai OAE a permission wrapper for VIVO profiles (provided the institution doesn't expose the VIVO UI). > 3. Profile updates > I believe that most profile data that lives in a VIVO instance is > harvested from reliable sources (pubmed, ldap, existing datastores, > a single admin user), rather than users updating it themselves, > which makes me think that we probably shouldn't be pushing updates > to vivo at all? I realise this is a bit of a radical shift but I > believe this makes the most sense as you want to display profile > data in the most accurate way and user might not always be correct > in what they are inputting. This is a radical shift indeed, but I'm hoping it's one we can consider. I don't think not allowing them to change anything at all is the way to go, as the harvesters can produce noise or incorrect entries, and Vivo does allow users to update data themselves. Asking people to update their profile data in Vivo itself would make it clear that their profile info is served from a single central system and would reduce the amount of code that Sakai OAE has to maintain. However, if we ask people to edit their profile data in Vivo itself, we do have to expose the Vivo UI, which might then affect the profile privacy strategy. > 4. Linking Sakai users and VIVO profiles > I'm not entirely sure yet how we will do this. I've sent a mail to > the VIVO list asking what the recommended approach is but I'm > waiting for an answer. For now I'm doing a search in vivosolr on > "lastname, firstname" to get the vivo id but this is clearly not the > way to go. They are planning to provide LDAP support which would > certainly be helpful, but again, it's not there yet. It feels like Sakai could keep a property on the user nodes that specifies the corresponding Vivo userid. This property could then be set in a number of ways. > 5. Bundling VIVO with OAE. > There are some talks within VIVO to move to OSGi and have it run in > an Apache Felix Container. They are still a long way of of that goal > though. I'm not entirely sure if running VIVO within the same JVM > would be a good idea anyway as it seems to be fairly resource hungry. If this is the case, it almost feels like Sakai OAE should come without Vivo out of the box and therefore only offer the most basic profile functionality (firstname, lastname, picture and email). The profile sections, visualizations, etc. can then become available once a Vivo instance is coupled to Sakai OAE. Other than that, we should probably also spend some effort on thinking about how this fits into a multi-tenant strategy. Hope that helps, Nicolaas _______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
