A new (editing) frontend for VIVO

Hector Correa, Steven McCauley

Keywords: Frontend development, REST API, Editing

TL;DR: Adding new editing interface to VIVO (via client applications that use VIVO as a backend)

Abstract:

A couple of years ago at Brown University we wrote a new frontend for the public interface of our VIVO installation. This new frontend provided a modern look and feel for searching and displaying information on Researchers at Brown[1] and was well received by researchers and the public in general. This year we are focusing on adding an editing interface to this application to allow researchers to easily add or update the information on their VIVO profile including publications, research statements, collaborators, appointments, and so on.

In this presentation we'll show the general architecture of our VIVO installation, including the different services and applications that interact with it, we'll discuss the challenges during the development of the new editing features, and some of the gains that our approach has given us.

The new editing interface is built on top of the Ruby on Rails application that we built for the public interface a couple of years ago. This application interacts with a typical REST API service that communicates with VIVO to submit the changes to the triplestore.

One of the lessons that we've learned during our years using VIVO has been that we can preserve Linked Data in the backend (as VIVO natively does) while at the same time provide traditional REST API endpoints to allow other applications, written in a variety of programming languages, to consume and in this case update the information. This approach has the advantage that we can run sophisticated SPARQL queries against the triplestore (for example to generate networks graphs of collaborators to power visualizations) while at the same time isolate client applications written in Python and Ruby from the triplestore and RDF complexities, and instead, expose the data to those applications in ways that they can easily consume, for example via a REST API passing JSON back and forth.

[1] https://vivo.brown.edu/

Submission Type: presentation proposal