Extending VIVO infrastructure to support linking information between EarthCollab VIVO instances Huda Khan, Matthew Mayernik, Keith Maull, M. Benjamin Gross, Mike Daniels, Steve Williams, Linda R. Rowan, Sandy Payette, Erica Johns, Dean Krafft, Dave Eichmann

The Flow of This Talk Bigger Picture Background: EarthCollab Demo Architecture VIVO as a Service Issues and Future Directions Questions and Suggestions

Bigger Picture How to lookup and render external VIVO (and other) content? How to output VIVO information so it can be rendered elsewhere? VIVO APPLICATION VIVO APPLICATION RDF Content RDF Content

Bigger Picture Alien VIVO: “Please accept my data request” Picard VIVO: “I have no idea what you’re saying!” Star Trek: The Next Generation https://en.wikipedia.org/wiki/Darmok Image retrieved from: http://cdn-static.denofgeek.com/sites/denofgeek/files/styles/insert_main_wide_image/public/darmok.jpg?itok=jEXtWouO

Bigger Picture How to implement VIVO as a “service”? VIVO APPLICATION Profile/ Application/ Component Requests Profile Requests VIVO APPLICATION VIVO APPLICATION Linked Data Linked Data HTML RDF Content RDF Content JSON HTML RDF Extending capability to support different levels of granularity, different formats Currently enabled external requests (other than SPARQL API)

Bigger Picture: Questions Usefulness/utility of VIVO as a service Desired features? Additional use cases? Retrieve full profile or components? Additional challenges or opportunities? Part of VIVO core code?

Background: EarthCollab Enable discovery of people, datasets, publications, other research products “More coherent methods of information and data discovery” Geoscience-based case studies Bering Sea Project, data archive hosted by NCAR’s Earth Observing Laboratory UNAVCO, geodetic facility and consortium NSF Earthcube Building Block UNAVCO, UCAR, Cornell University PI(s): Matthew Mayernik (NCAR), Mike Daniels (NCAR), Dean B. Krafft (Cornell), Linda Rowan (UNAVCO)

Background: Linking VIVOs Information distributed across different VIVOs VIVO VIVO Matt Pritchard Matt Pritchard UNAVCO datasets Cornell publications

Background: Linking VIVOs Retrieving info from a different VIVO instance Without ingesting new data While preserving original brand/identity of source and destination VIVOs Architectural concerns Using and expanding VIVO’s built-in structures and processes VIVO as a service

Live Demo Let’s show an example …

Demo: Overview Lookup, Connect, Retrieve, Display VIVO VIVO Cornell Service Search Matt Pritchard Link Matt Pritchard same as? extract + display Cornell publications Request information on linked URIs Cornell publications UNAVCO datasets Information Retrieved and displayed

Demo: Overview Bidirectional link and display VIVO VIVO Cornell Service UNAVCO Service Bidirectional same as link Matt Pritchard Matt Pritchard same as? extract + display Cornell publications Cornell publications Information Retrieved and displayed UNAVCO datasets UNAVCO datasets

Architecture: Extensions VIVO APPLICATION VIVO Application Framework VIVO APPLICATION VIVO Application Framework Lookup Matt Pritchard Extension/ Expansion Extension/ Expansion URI for Matt Pritchard Request publications Output publication info

Architecture: Extensions Lookup framework extended to look for external entities Reusing custom form and generator framework to link in lookup Lookup services already supported: Used to look for internal entities (usually) Linking to external entities through specialized services Vocabulary lookup Open VIVO Sparql API

Architecture: Lookup Look for existing internal entities Autocomplete Controller VIVO Solr User-facing form External Lookup Controller External Solr (or other lookup) Look for external entities RDF Population Processes Custom form for external lookup External lookup information/ configuration Generate RDF based on external lookup N3 Editing Framework

Architecture: Lookup Service configuration in RDF earthcollab:unavcoSolrLookup … earthcollab:hasSolrAPIURL "http://vivo.unavco.org:8081/vivodevsolr/collection1/select?"; earthcollab:hasEndpointURL "http://vivo.unavco.org:8081/vivodev"; earthcollab:hasEndpointLabel "UNAVCO" .

Architecture: Extensions Information output extended to provide JSON representation Selected properties OR all profile content Reusing data resulting from SPARQL queries tied to properties through list views RDF representation of all content visible on profile page Reusing SPARQL queries and converting to constructs to retrieve RDF Information output already supported HTML rendering of profile page Linked data

Architecture: Extensions VIVO APPLICATION VIVO Application Framework HTML Core VIVO Profile Linked Data JSON Extensions RDF

Architecture: Extract Information and Display JSON output statements": [ { "allData": { “dateTime": "2014-01-01T00:00:00", "subclass": "http://vivoweb.org/ontology/core#Dataset", "infoResource": "http://connect.unavco.org/individual/dat798945", "authorship": "http://connect.unavco.org/individual/n446526", "infoResourceName": "Malawi Rifting GPS Network, CTPM-Chitipa P.S.“ }}..]

Architecture: Extract Information and Display Profile output process and formats Package Results Request HTML Individual Profile Sparql Queries Freemarker Template Convert to JSON Template JSON Convert to Construct Queries RDF Additional JSON functionality: property-based information retrieval (e.g. publications)

Issues Proper way to enable lookup across VIVO? Controlled access to known request origins Sparql API? Linked Data Fragments? Common framework for lookup services? Vocabulary search Open VIVO External individual search Additional linked data sources/lookup CTSASearch? DBPedia? Same As: Repercussions

Architecture: Extract Information and Display The Monk Method for Copying Solr Indices Monk 1: “Now copy each field of the Solr records correctly so we can make a copy of the search index”. Monk 2: “I’m not at all sure about this schema.” Image from http://www.splendorofthechurch.com.ph/wp-content/uploads/2013/01/medieval.jpg

Issues Information extraction and rendering Modularize? Make independent of each other? VIVO as rendered page vs. VIVO as metadata/data Rendering may be different between source and destination Ontologies may be different VIVO application may have customized rendering Associate rendering code with application version

VIVO Application Framework VIVO As A Service VIVO APPLICATION VIVO Application Framework Template For Publications Templates for Profile RDF Publications JSON HTML

Issues Multiple external data sources User interface design Usability concerns Handling external data source being unavailable Handling duplication between external and internal information

Moving Forward VIVO as a service Sparql API Application-specifics (e.g. version number) Response to requests for specific services/patterns Publications Datasets Extract and render these specific requests As HTML As JSON As RDF

VIVO Application Framework VIVO Application Framework VIVO As Service VIVO APPLICATION VIVO Application Framework VIVO APPLICATION VIVO Application Framework VIVO version? Extension/ Expansion Extension/ Expansion Contact info as JSON? Positions as RDF? Publications as HTML?

Implementation Currently: VIVO Versions 1.8.1 and 1.7 Third/fourth tier GitHub RDF Export: Update to 1.9 for pull request

Related Work EarthCollab presentations Connect UNAVCO, A VIVO for a Scientific Community - M. Benjamin Gross, Linda R. Rowan, Matthew Mayernik, Michael Daniels, Huda Khan, Dean Krafft EOL Artic Data Connects – Don Stott, John Allison, and C. Brooks Snyder Using VIVO for Scientific Applications - Matthew Mayernik, Anne Wilson and John Furfey VIVO in a networked research ecosystem https://wiki.duraspace.org/pages/viewpage.a ction?pageId=69015585

Questions/Suggestions Usefulness/utility of VIVO as a service Desired features? Additional use cases? Retrieve full profile or components? Additional challenges or opportunities? Part of VIVO core code?

Supported by US National Science Foundation, grants 1440293, 1440213, 1440181 http://earthcube.org/group/earthcollab Contact us! Thank You!