VitroLib extends Vitro, the open source ontology and instance editor that provides the ontology-agnostic semantic application underpinning VIVO, the researcher profiling system. VitroLib generates content display and content editing interfaces based on BIBFRAME, Bibliotek-o which extends BIBFRAME, and related ontologies.
What is Vitro?
Vitro is a general-purpose web-based ontology and instance editor with customizable public browsing. Vitro was originally developed at Cornell University, and is used as the core of the popular research and scholarship portal, VIVO. Vitro is an integrated ontology editor and semantic web application implemented as a Java web application that runs in a Tomcat servlet container. With Vitro, you can: create or load ontologies in the Web Ontology Language (OWL) format; edit instances and relationships; build a public web site to display your data; and search your data with Apache Solr.
How does VitroLib extend or customize Vitro?
Similar to how VIVO adds VIVO ontology-specific customizations for information display and entry, VitroLib adds customizations for the display and addition of BIBFRAME and related ontology information. Being ontology-agnostic, Vitro can support the display and editing of BIBFRAME data, but we opted to explore more usable design that could support catalogers in their workflow than that provided by Vitro which is better suited for an audience that has greater familiarity with ontology editing tools. Furthermore, we refactored code responsible for integrating vocabulary lookups from VIVO into the Vitro layer and wrote implementations for looking up Questioning Authority sources. We also explored how to enable more client-side configuration of property-specific customizations. The work we did to translate and integrate SHACL is defined (here).
Examples of content-specific or workflow-specific customizations
We used Vitro’s built in configurations or display and editing customization support to modify the default Vitro behavior to better suit cataloging workflows or provide content-specific behavior. We included a link on the home page to provide quick access to catalogers for cataloging a work/instance/item. This link used a custom editing form that generated three related entities: work, instance, and item, and then redirected the user to the resulting work entity profile page.
We used “faux properties” which provide configurable display of labels, display, and links to custom editing forms to map from SHACL to provide properties and property groupings that could help catalogers with viewing and navigating the system. We included work, instance, item specific templates. These templates defined the broad category, i.e. work, instance, item, and not just the specific ontology class applicable to the entity. We did not want both a faux property and the underlying ontology property to show up on a page, as it would be confusing to users to see, for instance, both the faux property “agent activity and role” as well as the ontology property “hasActivity” when the first is what we want the user to use. We updated content-specific templates to hide the ontology property if a faux property masking that property is present. We also include custom editing forms for several different properties to help provide a more usable interface that didn’t require catalogers to know all the details of the ontology.
Integrating Questioning Authority and other lookups
Lynette Rayle and Dave Eichmann have worked on creating an infrastructure and code for enabling a configurable approach to integrating “Questioning Authority” or QA lookups. Lynette has worked on creating configurable linked data lookups using the QA Ruby on Rails gem. We refactored the VIVO lookup code to provide JAVA interfaces in the Vitro layer that could then be implemented in VitroLib to enable lookups to be available to the VitroLib interface. We added QA implementations for Library of Congress Name Authority File, Library of Congress Subject Headings, and the Library of Congress Genre Form Terms QA lookups that were made available on a server setup for this grant. We also incorporated some contextual information made possible by Lynette’s implementation to enable more information to be displayed to the user.
Below are some screenshots showing the integration of QA lookups into the VitroLib interface. Figures 1 and 2 below the integration of lookups from the Library of Congress Name Authority File where a user can select from autocomplete results. We modified the lookups front-end to enable the “Verify this match” link to open up the Real World Object found in the result. From cataloger feedback, we know the desired behavior is to open up the authority file instead but this modification enabled some level of review of the selected result. Also, Figure 1 shows ISNI as a potential lookup source which is not implemented as a QA authority but which was implemented as a VitroLib search option.
Figure 1: LCNAF Lookup
Figure 2: Verify this match link next to selected LCNAF lookup
Figures 3 and 4 below show the integration of the Library of Congress Genre Forms lookup using additional context in the search results. The user types in “animation” when adding a Genre Form property and is able to see multiple search results which display alternate labels as well as links to broader and narrower terms where applicable. Clicking on the search result name will open up the corresponding Library of Congress Genre Form page . The design of these tables was influenced by the mockups that Lynette Rayle had designed for exploring contextual information retrieval in QA lookups.
Figure 3: Genre Form lookup with query
Figure 4: LCGFT lookup results
Figure 5 below provides an overview of the lookup process in the VitroLib implementation. The user’s query is carried from the interface to code within VitroLib that implements the Vitro search interface and that parses the query and makes the request to the Questioning Authority URL that performs the search and returns results in JSON. The VitroLib code then parses the results and returns them in a format understood by the VitroLib interface for display.
Figure 5: Overview of QA integration with VitroLib
Client-side configurations of custom forms
Linked Data Notifications (or LDN) Experiments
As part of work with Harvard, we experimented how we may integrated LDN into VitroLib. An RDF file specified a triple which used the “inbox” predicate to specify the LDN inbox URL. We were able to demonstrate a servlet that read these triples in and then was able to request inbox contents from the LDN inbox URL. This servlet thus demonstrated consumption of the LDN inbox.
We also added code that would write to the LDN inbox whenever data was added or edited through the interface. Vitro comes with reasoning code that is triggered when a user adds or edits information through the interface and this code can see which triples have been added or removed. The code we added as part of this experiment took those triples that were added and then submitted them to the LDN inbox that we defined in our RDF that was part of the system. We thus were able to both read form and write to an LDN inbox in VitroLib.