This documentation relates to an old version of VIVO, version 1.6.x. Looking for another version? See all documentation.
This document contains instructions on how to upgrade your installation of VIVO from Version 1.5 (or 1.5.1, or 1.5.2) to Version 1.6. This and other documentation can be found on the support page at VIVOweb.org
If you need to do a fresh install, please consult the Installing VIVO release 1.6, found on vivoweb.org, or the VIVO Installation Instructions.pdf file located in the
doc directory of the VIVO source code distribution. The installation document also has a list of the required software and versions.
For a description of the release contents see the Release announcement for V1.6.
Create backups of:
The VIVO distribution directory (which contains the source for VIVO 1.5 or VIVO 1.5.1)
The VIVO home directory (pointed to by your deploy.properties file)
The webapps directory in Tomcat
MySQL database (most people use mysqldump to create the backup)
If you have used temporary models in the database to stage ingested data, you will want to clear out any unneeded models that remain listed on the
Manage Jena Models page (under
Ingest tools). This step is especially important if these temporary models contain blank nodes, as this may cause unwanted or duplicate data to appear following the upgrade.The upgrade process is similar to the initial install process with the following exceptions:
distributetarget that will produce a file called
distribution.tar.gz. This compressed archive contains these files:
vivo.war-- a WAR file for the main VIVO application.
vivosolr.war-- a WAR file for the Solr application.
solrhome.tar-- a Solr home directory that is configured for use with VIVO.
deploy.propertiesfile has been split in two.
build.propertiescontains only the properties that are required for building VIVO.
runtime.properties, which must be created in the Vitro home directory, contains the properties that VIVO uses while running.If you are building to
deployto Tomcat (as with previous releases), then
build.propertiesmust contain these properties:
vitro.home-- note that this was
vitro.home.directoryin previous releases
build.propertiesfile requires only these properties:
In previous releases, Solr was deployed to Tomcat with a
RemoteAddrValve that would only permit access from certain IP addresses. Acceptable IP addresses were those which matched the regular expression pattern in the
vitro.local.solr.ipaddress.mask property.This has been removed because:
Sites that need to secure Solr are now left to their own devices.
In previous releases, the properties file for the VIVO logging system was called
default.log4j.properties. In release 1.6, this file has been renamed to
log4j.properties. This is so the developers and implementers will know where to look for the file.Note that
debug.log4j.properties, if present, will still override the default.
With release 1.6, the property group menu bar that was used on profile pages has been replaced by java script enabled tabs. When clicked, each property group tab will display the properties within that group while the contents of the previously displayed group will be hidden. The array of tabs also includes a "View All" tab that, when clicked, displays the contents of all the property groups.
The VIVO software now supports the development of SPARQL query data getters that can be associated with specific ontological classes. These data getters, in turn, can be accessed within Freemarker templates to provide richer content on VIVO profile pages. For example, the profile page for an academic department lists only the names of the faculty within that department and their titles, but with a SPARQL query data getter it is now possible to extend the faculty information to display all of the faculty members' research areas. Refer to this wiki page for details on how to use class-specific SPARQL query data getters:
VIVO now supports multiple profile pages for foaf:Persons. This feature, which is optional so installations can continue to use just the individual--foaf-person.ftl template, currently consists of two profile page types: a standard view, which is a redesigned version of the foaf:Person template in previous releases; and a quick view, which emphasizes the individual's own web page presence while providing summary VIVO information, such as current positions and research areas. The profile quick view requires the use of a web service that captures images of web pages. This web service is not included with the VIVO software. An installation will either have to develop their own service or use a third-party service, usually for a small fee depending on the number of images served. (Examples of these services include WebShotsPro, Thumbalizr and Websnapr.) For more information on how to implement multiple profile page views, refer to this wiki page:
For Release 1.6 the VIVO Home Page has been redesigned. The Search field beneath the "welcome" text now allows the user to limit the results of a search to a specific class group, such as people, organizations, etc. In addition, the browse-by-class-group display has been removed from the Home Page and replaced by multiple features, which include: a list of four randomly selected faculty members, including their titles and thumbnail images; a display of statistical data about the VIVO installation, such as the number of people, activities and organizations; and, optionally a global map showing researchers' areas of geographic focus.
The RDF files that initialize the data model have moved, in both the distribution and the runtime locations. In the distribution, they have been collected in one place, and reorganized to use a more consistent naming scheme. During the build process, they are copied to a location within the VIVO home directory, instead of residing in the webapp itself.If you have modified these RDF files, or added files of your own, you must adjust to the new locations accordingly.
|Old locations of RDF files|
under [Vitro]/webapp/web or [VIVO]/productMods
|New locations of RDF files|
under [Vitro]/webapp/rdf or [VIVO]/rdf
|WEB-INF/ontologies/app/menuload/displayTBOX.n3||rdf/displayTbox/everytime/||Was one file, now a directory|
|/WEB-INF/ontologies/app/menuload/displayDisplay.n3||rdf/displayDisplay/everytime/||Was one file, now a directory|
If you are using a three-tier build process, you will need to add two lines to the build script to accomodate the RDF files, and the language support (see below) So this:
VIVO 1.6 includes limited support for other languages, in addition to American English. This limited support is described as read-only support on public-facing pages.Read-only means that there is no provision for editing multi-language data or displays. Property values, ontology labels, etc. must all be provided in RDF files and ingested or otherwise inserted into the data model. The Page Management user interface does not support maintaining pages in multiple languages.Public-facing means that most of the pages used for site adminstration are only presented in American English.These two pages in the VIVO Wiki describe how to Build VIVO with multiple languages and how to Add a new language to VIVO.
The list of default types for Google Refine has changed, to accommodate changes in the ontology. If you are using Google Refine, you may need to change your runtime properties accordingly. The new defaults appear in
This release includes several settings to help developers by instrumenting the Freemarker templates and the SPARQL queries on the RDFService. Check the wiki for details, or look in the home directory in
For this release, the following browsers are supported.
deploy.propertiesfile into two files, as described below.
Store the new
build.properties file in the top level of the VIVO distribution directory. Store the new
runtime.properties file in your VIVO home directory.
|Properties in ||Properties in |
|All other properties from |
|Note that |
If you prefer, you may start with
example.runtime.properties, make copies, and edit them to suit your installation. Remember, the
runtime.propertiesfile goes into your VIVO home directory.The properties below are new to
build.properties. They are optional, so you need not add them unless you want a value other than the default.
|Property Name||Example Value|
|Languages (in addition to American English) that will be built into your VIVO site. The languages must be found in the |
runtime.properties. They are optional, so you need not add them, unless you want a value other than the default.
|Property Name||Example Value|
|Tell VIVO to generate HTTP headers on its responses to facilitate caching the profile pages that it creates. This can improve performance, but it can also result in serving stale data. Default is false if not set. For more information, see the VIVO wiki page: Use HTTP caching to improve performance|
|Force VIVO to use a specific language or Locale instead of those specified by the browser. This affects RDF data retrieved from the model, if RDFService.languageFilter is true. This also affects the text of pages that have been modified to support multiple languages.|
|A list of supported languages or Locales that the user may choose to use instead of the one specified by the browser. Selection images must be available in the i18n/images directory of the theme. This affects RDF data retrieved from the model, if RDFService.languageFilter is true. This also affects the text of pages that have been modified to support multiple languages.|
|languages.selectableLocales||en, es, fr_FR|
|On the VIVO home page, display a global map highlighting the geographical focus of foaf:person individuals. The default is |
|MultiViews for foaf:person profile pages. VIVO supports the simultaneous use of a full foaf:Person profile page view and a "quick" page view that emphasizes the individual's own webpage presence. Implementing this feature requires an installation to develop a web service that captures images of web pages or to use an existing service outside of VIVO, usually for a small fee. The default is |
|Setting this property causes VIVO 1.6 to produce extended responses to requests for linked data. This provides compatibility with earlier releases. The default is |
Extended linked data is costly, in terms of server resource. Typically, extended linke data contains 50% more information than its non-extended equivalent, and takes 10 times as long to produce.
Extended linked data will not be supported in future releases of VIVO.
externalAuth.buttonTextis no longer used. You can specify the text of the external login button by adding a property to
external_login_text = Log in using BearCat Shibboleth
Special notes regarding source files
- This process assumes any changes made to the application were made in the source directory and deployed, and were not made directly within the Tomcat webapps directory.
- In many cases, simply copying the modified files from your original source directory will not work since the files on which they are based have changed. It will be necessary to inspect the new source files and add any changes to them at that time.
- NIH-funded VIVO implementations will need to apply the Google Analytics Tracking Code (GATC) to
googleAnalytics.ftlin the theme:[new_source_directory]/themes/[theme_dir]/templates/googleAnalytics.ftlA sample
googleAnalytics.ftlis included in the built-in theme. This file serves only as an example, and you must replace the tracking code shown with your institution's own tracking code. For additional information about the GATC for the NIH-funded VIVO implementation sites and a copy of your institution's tracking code, see the VIVO Google Analytics wiki page.
INFO: Server startup in XXXXX ms
In addition to the logs described in step 8 of the previous section, the knowledge base migration process will log copies of all additions and deletions that were made to the knowledge base in the following files in the VIVO home directory:
An N3 file containing all the statements that were removed from the knowledge base.
An N3 file containing all the statements that were added to the knowledge base.