VIVO Release 1 V1.6 Upgrade Guide

October 9, 2013 - Upgrading from Release 1 V1.5 to Release 1 V1.6

This document contains instructions on how to upgrade your installation of VIVO from Version 1.5 (or 1.5.1) 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 VIVO Release V1.6 Installation Guide found on vivoweb.org or the install.html 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.

Table of Contents

  1. Before Performing the Upgrade
  2. Noteworthy Changes
    1. VIVO becomes more portable
    2. Solr is no longer secured
    3. Log4J properties file renamed
    4. Property groups now displayed in a tab format
    5. Class-specific SPARQL Query Data Getters
    6. The foaf:Person template has been re-located.
    7. Multiple foaf:Person Profile Pages
    8. Home Page Re-design
    9. Auto-loaded RDF files move to the Home directory
    10. Support for additional languages
    11. More compact responses to Linked data requests
  3. Upgrade Instructions
  4. Knowledge Base Migration
  5. Review the VIVO Terms of Use
  6. Next Steps

I. Before Performing the Upgrade


Create backups of:

The upgrade process is similar to the initial install process with the following exceptions:

II. Noteworthy Changes

III. Upgrade Instructions

1. Download the new distribution file and unpack it into a new source directory.

2. Separate your existing deploy.properties file 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 build.properties Properties in runtime.properties
vitro.core.dir
vitro.home
tomcat.home
webapp.name
 All other properties from deploy.properties
Note that vitro.home replaces vitro.home.directory
Note that vitro.local.solr.ipaddress.mask is no longer used.

If you prefer, you may start with example.build.properties and example.runtime.properties, make copies, and edit them to suit your installation. Remember, the runtime.properties file 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 languages directory of the VIVO distribution. See the VIVO Wiki for more information.
languages.addToBuild es_MX

The properties below are new to 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
http.createCacheHeaders true
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.
languages.forceLocale en_US
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
For developers only. Defeat the Freemarker template cache, so each template is read from disk on each request. This permits developers to immediately see the effect of changes to the template. The default is false, which means that a cached copy of each template will be used for 60 seconds before the disk is checked for a new version.
Setting this option to "true" slows down VIVO performance.
developer.defeatFreemarkerCache false
For developers only. Defeat the cache of language-specific text strings, so the language file is read from disk on each request. This permits developers to immediately see the effect of changes to the text strings. The default is false, which means that the language file is read when VIVO starts up, or when a new theme is selected.
Setting this option to "true" slows down VIVO performance.
developer.defeatI18nCache false
For developers only. Add starting and ending delimiters to each Freemarker template, so you can see which template were invoked by viewing the generated HTML. The default is false.
Setting this option to "true" slows down VIVO performance.
developer.insertFreemarkerDelimiters false
On the VIVO home page, display a global map highlighting the geographical focus of foaf:person individuals. The default is enabled.
homePage.geoFocusMaps enabled
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 disabled.
MultiViews.profilePageTypes disabled
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 false.
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.
serveExtendedLinkedData true

Note that the property named externalAuth.buttonText is no longer used. You can specify the text of the external login button by adding a property to all.properties like this: 

external_login_text = Log in using BearCat Shibboleth

3. Apply any previous changes you have made to the new source directory.

Special notes regarding source files

4. Apply any previous changes you have made to the RDF initialization files. See the section on the Auto-loaded RDF files above for more details.

5. Stop Apache Tomcat and from your VIVO source directory, run ant by typing: ant all

6. Start Apache Tomcat and log into VIVO as the root user when the upgrade is completed. Depending on the size of your database, the migration process may take up to several hours. When it is complete, you will see a message in the catalina.log file that the server has started.

INFO: Server startup in XXXXX ms

7. As root or an administrator, request a rebuild of the Solr search index: Go to the "Site Admin" page and click on "Rebuild Search Index" under the heading "Refresh Content".

8. Review the knowledge base migration logs. The knowledge base migration process described in the next section will create logs in a subdirectory of the VIVO home directory:

(home directory)/update/logs/knowledgeBaseUpdate.(timestamp).log
A log of a summary of updates that were made to the knowledge base. This file should end with "Finished knowledge base migration". If this file contains any warnings they should be reviewed with your implementation team representative to see whether any corrective action needs to be taken.
ontologies/update/logs/knowledgeBaseUpdate.(timestamp).error.log
A log of errors that were encountered during the upgrade process. This file should be empty if the upgrade was successful. If any errors are encountered you will need to rerun the knowledge base migration.

9. Load the About Page .N3 file (optional). Release 1.6 provides an "about VIVO" page that is editable through the GUI, using the Page Management functionality. If your installation has a customized version of the About Page and you do not need to have it accessible via Page Management, then skip this step. Otherwise, here are the instructions for loading the About Page .N3 file:

  1. Once the VIVO application is running, go to the Site Admin page and click the "Ingest Tools" link under Advanced Data Tools.
  2. From the Ingest Menu click the "Manage Jena Tools" link, and then click the "RDB Models" button.
  3. Locate the "vitro-kb-displayMetadata" model and click the "load RDF data" button.
  4. Click the "Browse" button to upload the file from your computer and select the aboutPage.n3 file located here in the VIVO source: productMods/WEB-INF/ontologies/app/aboutPage.n3.
  5. Select N3 as the file type from the drop-down list and then click the "Load Data" button.
  6. Restart tomcat.

If your installation has a customized version of the About Page, but you would like to make its content editable through the GUI, follow the above steps and then use Page Management to update the fixed HTML content.

IV. Knowledge Base Migration

Changes to the VIVO core ontology may require corresponding modifications to the knowledge base instance data and ontology annotations. Each time VIVO starts up, it will initiate a process to examine the knowledge base and apply necessary changes. This process should be very quick on subsequent restarts if no data using the 1.5 ontology has been reintroduced. The knowledge base migration process for release 1.6 will make the following types of changes:

Instance data changes to align with VIVO-ISF
Obsolete predicates and types in the instance data will be updated where necesary to correspond to the current properties and classes in version 1.6 of the VIVO-ISF ontology. Note that VIVO 1.6 continues to make use of certain deprecated classes and properties that are not incompatible with VIVO-ISF. Most notable among these are the various subclasses of foaf:Person: these types will be unchanged by the VIVO 1.6 data migration, but may be removed in a future release.
Annotation property default values
If a site has modified the value of a vitro annotation (such as displayRankAnnot or displayLimitAnnot) so that it is no longer using the default, then that setting will be left unchanged. Note that the annotation settings for certain obsolete VIVO 1.5 properties will be preserved in a configuration file that applies settings to particular object properties based on the types of their subject and object individuals. This file is found in the VIVO home directory: (home directory)/rdf/display/everytime/PropertyConfig.n3
If a site is using the default value of a vitro annotation, and the default has been changed in the new version of the ontology, then the new default value will be propagated to the knowledge base.

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:

(home directory)/upgrade/knowledgeBase/changedData/removedData.(timestamp).n3
An N3 file containing all the statements that were removed from the knowledge base.
webapps/vivo/WEB-INF/ontologies/update/changedData/addedData.(timestamp).n3
An N3 file containing all the statements that were added to the knowledge base.

V. Review the VIVO Terms of Use

VIVO comes with a "Terms of Use" statement linked from the footer. The "Site Name" you assign in the "Site Information" form under the Site Admin area will be inserted into the "Terms of Use" statement. If you want to edit the text content more than just the "Site Name", the file can be found here:

[vivo_source_dir]/vitro-core/webapp/web/templates/freemarker/body/termsOfUse.ftl
Be sure to make the changes in your source files and deploy them to your tomcat so you don't lose your changes next time you deploy for another reason.

Next Steps

Now that you have VIVO up and running, please refer to the Site Administrator's Guide for information about its operation.