Versions Compared

Old Version 6

changes.mady.by.user Rebecca Younes

Saved on

compared with

New Version Current

changes.mady.by.user Simeon Warner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The Vitro-based editing tool ("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. Like VIVO, VitroLib is a full-scale application built on top of the Vitro core, but customized for original cataloging in RDF. 

We used the VitroLib prototype to experiment with cataloging in linked data using the Afrika Bambaataa Collection at Cornell and also set up instances for use in the ARM workshop and to implement ArtFrame-specific metadata application profiles.

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

...

The Cornell LD4L Labs project team will provide library technical services and digital collections catalogers with Vitro-based data editing, display, and dissemination environments that will support the creation and incorporation of subject and collection-specific ontologies to describe the unique aspects of the collection in a structured, extensible, and shareable manner. The tools will also support easy linking to existing external linked data vocabularies and published globally-resolvable entities (e.g., Getty, FAST, WorldCat Entities, LinkedBrainz, and Digital Science GRID).

The Vitro-based editing tool ("VitroLib") will be used by LD4P Partners in their metadata production pilots. These pilots will specifically include the Afrika Bambaataa Collection at Cornell and the Columbia Art Properties Collection, but may include other LD4P efforts as well. The Vitro metadata production approaches will be informed by the use cases developed by other LD4P Partner projects.

Like VIVO, VitroLib will be a full-scale application built on top of the Vitro core, but customized for original cataloging in RDF.

Work plan

Stage 1: Exploration and documentation

The goal of this stage is to provide an early VitroLib prototype, with accompanying documentation and instructional materials, as a basis for preliminary exploration by LD4P partners, and to serve as a starting point for initial requirements analysis and feature specification for the more fully-featured version of Stage 2, described below. The work products of this stage are:

  1. A prototype VitroLib application built on Vitro 1.8.1, including some sample customizations for the ontology (LD4L-O) and recommended external vocabularies developed in the LD4L 2014-2016 project. 
  2. A Cornell-hosted, shared sandbox instance of this version of VitroLib for exploration by LD4P partners. Sample instance data using these vocabularies, produced by the MARC-to-RDF converter produced during the 2014-2016 project, has been loaded into the instance. 
  3. A series of introductory webinars based on this verion of VitroLib, including installation and configuration, ontology browsing; instance data browsing, editing, and querying; display customization; and user management.
  4. Full documentation of the stand-alone Vitro application, which has not heretofore existed. This will be based on the VIVO 1.9 documentation, include technical documentation and customization options for developers, and site and data management documentation for site administrators and editors. As the project progresses (see Stage 2 below), VitroLib-specific documentation will be provided as needed.

Stage 2: VitroLib application development

The goal of this stage is to progressively build a more fully featured application based on iterative requirements and feature specification developed in collaboration with the LD4P partners who are using VitroLib as their metadata editor. This version will be built on Vitro 1.9, and will provide display and editing customizations for the core ontology recommendations of the LD4L Labs/LD4P ontology working group. The application will be further customizable for the LD4P ontology extensions. The work products of this stage are:

  1. Cornell hosting of institution-specific VitroLib instances for some LD4P partners. These will include Cornell, Columbia, and possibly others to be identified.
  2. Provision of an installation package for LD4P partners who will host their own instances.
  3. Iterative development of the application based on close collaboration with and feedback from LD4P partners as they use the tool. These customizations will include development of custom data entry forms and data display based on the underlying ontologies developed and recommended by the LD4L Labs/LD4P ontology working group.
  4. Improvements to the Vitro core technology identified during the course of editor customizations. Design and implementation of this improvements will be based on discussions with and recommendations from the VIVO community, with the expectation that these will be merged back into the Vitro code repository for the benefit of the VIVO community and other Vitro users. An immediate task is to fully separate the VIVO and Vitro code bases as a prerequisite for clean development of another Vitro-based application.

Current status

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.

Development and Design Process

The design and development of the VitroLib prototype was a collaborative effort that spanned multiple institutions and roles.  Early on, we recognized the need for using a user-centered design approach to understand how catalogers approach their tasks and how to support those tasks using a new underlying model and a new interface.  We were fortunate in being able to tap into cataloger knowledge using multiple approaches from informal conversations, focused meetings, usability evaluations, and hands-on experiments with the prototype.  We'd like to thank all the catalogers who participated in meetings or usability evaluations including the catalogers at Cornell, Harvard, Princeton, Columbia, and Stanford.  Thanks also to all those who attended our VitroLib conference calls. The sections below include links to more information about the process and lessons learned from our iterative approach to design.

The development process of VitroLib focused on creating custom editing and display interfaces using Vitro's built-in RDF editing and management processes.  We quickly realized that much customization would be needed and focused the initial part of our development process on enabling client-side configuration of custom editing forms (where Vitro traditionally uses server-side configuration).  We uses this streamlined approach to generate all the custom editing forms used in the prototype.  In addition, for the HipHop collection, we relied on feedback from Cornell catalogers to identify core fields that could be used in the initial work/instance/item creation form.  When the opportunity to specify how the ontology should actually behave arrived in the form of SHACL metadata application profiles, we constructed a process for querying and translating those profiles into VitroLib configuration for display and editing.  Further details on the streamlined customizations and SHACL translation can be found linked in the sections below.

Setup and Installation

The GitHub code repository is available here: Github code repository . A series of VitroLib tutorials are available on YouTube which cover setup and installation and Vitro features that are available in VitroLib.  Some additional details are available here.

Architectural Overview and Customizations

VitroLib development included streamlining of custom forms as well as integrating Questioning Authority lookups and experiments with Linked Data Notifications.  An overview of the architecture and these customizations is included here.

Usability and User Experience: Lessons Learned

Certain higher level patterns emerged from cataloger feedback and the usability testing we conducted.  These lessons are discussed here.

Walking through the UI

Screenshots showing an example of using VitroLib to create a new work, instance, and item are included here.

VitroLib and SHACL

Our work for translating SHACL into VitroLib configuration is discussed here.

Harvard's use of VitroLib for FGDC and HFA

Related publications and presentations

Here is a list of VitroLib-related presentations. 

Publications and presentations related to LD4L-Labs can be found here.

 

 

 

...