This documentation relates to an old version of VIVO, version 1.10.x. Looking for another version? See all documentation.
VIVO provides an online portal to showcase the academics, their work, and their professional relationships.
Linked Open Data
All information within a VIVO system is represented natively in the RDF data model - everything is expressed as subject - predicate - object statements. These statements are written to a triple store, and are made available as RDF documents for each resource, in a number of serialisation formats.
All content is indexed using Solr - a popular open source search platform built on Lucence.
VIVO provides simple navigation through menus which lead to lists of various types of entities – people, organizations, research. An Index provides access to lists of all types of entities. The Capability Map provides a graphical method for finding people by concepts.
Optimisations for Google Indexing
VIVO embeds structured data - hcards and schema.org - into profile pages to better support Google indexing. It also creates a sitemap.xml for all of the profiles in the system, and includes a link to this sitemap in the robots.txt.
It is encouraged that you should register your VIVO instance in Google Webmaster Tools and submit the sitemap.xml for better visibility of how Google is indexing your content.
Support for Modern Browsers
Getting Data into VIVO
Manual Data Entry
All screens in VIVO can provide for data entry, for users logged in with sufficient access. There are numerous roles that VIVO provides - from administrators that can edit any of the data in the system, to self editor privileges for users so that they can edit their own profile and related information.
Automated Data Entry
It is possible to add data to VIVO using automated tools. VIVO provides a SPARQL update endpoint, which can be used by external tools to manipulate the data, or the VIVO Harvester provides a means to acquire and transform data, and load it directly into the triple store.
VIVO has internal storage for user accounts, and can authenticate based on a password (stored as a hash), or via an external authentication mechanism, such as Shibboleth. For externally authenticated users, an internal user account is still required, and is matched based on the external ID.