This documentation covers the latest release of VIVO, version 1.10.x.
If you are able to help contribute to this documentation, please contact
sysadmin at duraspace dot org
Looking for another version? See all documentation.
VIVO provides an online portal to showcase the academics, their work, and their professional relationships.
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.
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.
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.
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.