Calls are held every Thursday at 1 pm eastern standard time (GMT-5) – convert to your time at http://www.thetimezoneconverter.com

Please add additional agenda items or updates – we always welcome suggestions

Updates

• Weill Cornell – _1) Linux VM for VIVO doing very well. Still in development. Allocated 6GB memory for the web app and Harvester and see how it goes. Also no more loss of DB connectivity that we saw with Solaris. Still not sure why it happened. 2) Still working on single sign-on using Shibboleth._3) Continue working on mapping physician data (board certification, expertise etc) to VIVO ontology.
• Indiana – 1) working on the improved Map of Science for this release. 2) hiring an intern to convert ego-centric visualizations to HTML5 for the 1.6 release. 3) Katy is aware of the implementation of OpenSocial for VIVO, but modifying visualizations to work as OpenSocial gadgets will require significant time. 4) There's currently no way to turn off visualizations entirely, and it would be helpful to have more requirements. 5) Work is continuing on developing and testing an intermediate relational database model for ingest of common types of VIVO data
• Florida – 1) Modifying people ingest to do updates rather than full removal and replacement of HR data. 2) Cleaning up data from their Division of Sponsored Research. 3) Nicholas and Laura will be implementing the alpha version of the data cleanup tool Joe McEnerney has developed at Cornell to handle duplicate data detection and merging/removal
• Cornell – 1) moving into final preparation phase for mid-June code freeze

Special Guest Appearance

Nicholas Skaggs, formerly of UF and noted Harvester developer, will be calling in to describe deployment with Juju:

Howdy everyone. This past week I spent some more time getting my hands dirty with juju: https://juju.ubuntu.com

In short, juju lets you quickly deploy servers running services without sophisticated setup or expertise. Additionally, it allows you to deploy locally on your own hardware (using an LXC container), on a local server (using MAAS), on an openstack cloud provider or amazon ec2. For this reason you can even migrate between them with ease.

Naturally, I thought this may be of interest to the community for deploying vivo, and related tools like the harvester, google refine, joseki, etc. To that end I have created the first pass at a juju "charm", as they are called, for vivo itself. The code is currently sitting in a bzr branch, but can easily be moved or hacked on if there is interest. Ohh, I should mention juju runs on macs (via homebrew) or ubuntu linux.

https://code.launchpad.net/~nskaggs/charms/precise/vivo/trunk

There is alot of really nice things that makes deploying vivo and running your deployment on juju. I'll make a point to try and be on this week's developer call (it's been difficult since I am usually in a meeting at that time) to discuss more if people are interested.

Report on the Implementation Fest

Vince, Eliza, John, Alex, and Jon attended and presented along with Mike Conlon, Kristi Holmes, Nicholas Rejack, and Paul Albert.

• For materials, see the 2012 VIVO Implementation Fest page on this wiki, where presentations will be linked, or the presentation repository
• A guest speaker, Debbie Brodt-Giles from the National Renewable Energy Lab, demonstrated OpenEnergyInfo, a large linked open data site affiliated with Data.gov and maintained primarily in MediaWiki, that also includes a number of visualizations implemented in Exhibit
• update on Pubmed harvesting from discussions at the Fest
• A new, unified SPARQL Resources page (thanks to Nicholas Rejack)

Notes from the call

• a lot of people doing interesting stuff, and with lots of questions – no question of not filling the time, and presentations had remarkably little overlap
• a number of people interested in having a public-facing VIVO with less information than a behind-the-firewall version, whether affecting the visualizations offered or the data itself (NYU, Nebraska, Scripps)
• interest in being able to crawl other VIVO sites, and having a SPARQL endpoint be a default part of a VIVO installation
• a lot of interest in author disambiguation
• we need to introduce and explain the concept of graphs, especially if VIVO will start taking more advantage of storing data in different graphs
• some people are thinking of VIVO as an integration point for data from multiple data sources, storing multiple identifiers from different systems
• some sense that next year's event should have more unstructured time for bring-your-laptop, hands-on work with data or joint exploration of customizations or other simple modifications to VIVO, with the idea that more progress can be made in a day of face-to-face work than a week of trading messages on a listserv

New site for networking about VIVO implementations and related tools

Vince set up a VIVO site on Amazon to serve as a demo and a place to put information about VIVO exploration and implementation efforts (as well as production sites). We will provide log in information on the call and encourage all sites to put information about the version of VIVO they are running, the people involved, and additional tools used.

Feedback is welcome on what else could be added.

Notable Development List Traffic

Lots of traffic this week – over 75 messages – if I've missed one of special interest, please add it here.

• maintaining localnames when moving data from one VIVO instance to a VIVO on a new server with a new namespace – to support the use case of providing VIVO data to another unit on campus for harvesting, and wanting a unique id them to store and match on.
• dealing with missing most specific type inferences, differences between running a SPARQl query from Java vs. the interactive interface, and getting a model that is the union of both abox and tbox statements. Have to state with the query that you want to use the ARQ syntax – the interactive interface does that for you. Still a question of why the re-computing of the inference model is not generating the expected statements. Stella would like to have Vince look at the new RDF API in VIVO 1.5 to assess the extent of Harvester modifications required to use that API vs. the current JenaConnect.
• creating new custom forms – the current code may not support one use case identified, where the goal is to have program logic determine which URI to return to on submission of the form
• list views for data properties – see sample DOI link (near bottom of page), and now also a similar enhanced data property view on the SUNY Reach site. These implementations rely on string matching on property names, so a more robust per-property list view configuration as is currently available for object properties would be very helpful
• tools for batch additions and removals of RDF – some sites are doing large-scale additions and retractions more easily than others. This is an important area for gathering more documentation and feedback on best practices.
• caching – sites that do not support people in VIVO editing through single sign-on have implemented caching using tools that interact primarily with the Apache web server, such as Squid. Brian Caruso created an NIHVIVO-3770 for adding caching headers to VIVO; this issue overlaps another frequent topic of discussion, the need for a last modified date. A requirements analysis needs to be done to help decide what level of information on modifications is needed – e.g., globally, per individual, per property, and whether just the fact that a change has occurred is enough or whether more granular information is required. This also overlaps the use of the VIVO logging added to UF VIVO, which we hope to add to the trunk for VIVO 1.5.

Items for next week

Nicholas Skaggs will work with Stephen to see if he can demo the Juju charm work described above.

Call-in Information

1. Please join my meeting. https://www1.gotomeeting.com/join/322087560

2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.

Dial +1 (773) 897-3008
Access Code: 322-087-560
Audio PIN: Shown after joining the meeting

Meeting ID: 322-087-560

last meeting | next meeting