vivo/doc/upgrade-1.6.html

894 lines
47 KiB
HTML

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta charset="utf-8">
<title>VIVO Release 1 V1.6 Upgrade Guide</title>
<link rel="stylesheet" href="./css/doc.css" media="screen">
</head>
<body>
<div id="branding" role="banner">
<h1 class="vivo-logo"><a href="/"><span class="displace">VIVO</span></a></h1>
</div>
<!-- Start of content -->
<div id="wrapper-content" role="main">
<h1>VIVO Release 1 V1.6 Upgrade Guide</h1>
<small>
BOGUS DATE, 2013 - Upgrading from Release 1 V1.5 to Release 1 V1.6
</small>
<p>
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 <a href="http://vivoweb.org/support">support page</a>
at <a href="http://vivoweb.org/">VIVOweb.org</a>
</p>
<p>
If you need to do a fresh install, please consult the VIVO Release V1.6 Installation
Guide found on <a href="http://vivoweb.org/support">vivoweb.org</a>
or the install.html file located in the <code>doc</code>
directory of the VIVO source code distribution. The installation document also has a
list of the required software and versions.
</p>
<p>
For a description of the release contents see the <a href="./release.html">Release announcement for V1.6</a>.
</p>
<hr/>
<h3 id="tableofcontents">Table of Contents</h3>
<toc>
<ol class="roman2">
<li><a href="#preparation">Before Performing the Upgrade</a></li>
<li>
<a href="#changes">Noteworthy Changes</a>
<ol class="roman2">
<li><a href="#more_portable">VIVO becomes more portable</a></li>
<li><a href="#solr_insecure">Solr is no longer secured</a></li>
<li><a href="#log4j_properties">Log4J properties file renamed</a></li>
<li><a href="#tabMenu">Property groups now displayed in a tab format</a></li>
<li><a href="#sparqlDataGetters">Class-specific SPARQL Query Data Getters</a></li>
<li><a href="#foafPersonTemplate">The foaf:Person template has been re-located.</a></li>
<li><a href="#multiple">Multiple foaf:Person Profile Pages</a></li>
<li><a href="#homePage">Home Page Re-design</a></li>
<li><a href="#rdffiles">Auto-loaded RDF files move to the Home directory</a></li>
<li><a href="#language">Support for additional languages</a></li>
<li><a href="#BOGUS">ANYTHING ELSE?</a></li>
</ol>
</li>
<li><a href="#upgrade_process">Upgrade Instructions</a></li>
<li><a href="#kbm">Knowledge Base Migration</a></li>
<li><a href="#termsofuse">Review the VIVO Terms of Use</a></li>
<li><a href="#nextsteps">Next Steps</a></li>
</ol>
</toc>
<hr/>
<h3 id="preparation">I. Before Performing the Upgrade</h3>
<br/>
Create backups of:
<ul style="list-style-type: square;">
<li>
The VIVO distribution directory (which contains the source for VIVO 1.5 or VIVO 1.5.1)
</li>
<li>
The VIVO home directory (pointed to by your deploy.properties file)
</li>
<li>
The webapps directory in Tomcat
</li>
<li>
MySQL database (most people use mysqldump to create the backup)
</li>
</ul>
<p>
The upgrade process is similar to the initial install process
with
the following exceptions:
</p>
<ul>
<li>
You do not need to reinstall MySQL or recreate the MySQL database. Please
backup your MySQL database as noted above.
</li>
<li>
First-time login of the root account after the upgrade
process is complete will use the password previously set (not the
default password used on the first login after the initial
installation.)
</li>
<li>
The first time Apache Tomcat starts up after the upgrade, an automated
process will modify the knowledge base to align the
data with any ontology updates made for the new release. See the section on the <a href="#kbm">Knowledge Base Migration</a>
below for more information.
</li>
</ul>
<h3 id="changes">II. Noteworthy Changes</h3>
<ul>
<li>
<h4 id="more_portable">VIVO becomes more portable</h4>
<p>
The VIVO build script now includes a <code>distribute</code> target that will produce
a file called <code>distribution.tar.gz</code>. This compressed archive contains
these files:
<ol>
<li><code>vivo.war</code> -- a WAR file for the main VIVO application.</li>
<li><code>vivosolr.war</code> -- a WAR file for the Solr application.</li>
<li><code>solrhome.tar</code> -- a Solr home directory that is configured for use with VIVO.</li>
</ol>
These files can be used with Tomcat, or with any container that supports
the Java Servlet 2.4 Specification.
</p>
<p>
To permit this portability, the <code>deploy.properties</code> file
has been split in two. <code>build.properties</code> contains only the properties
that are required for building VIVO. <code>runtime.properties</code>,
which must be created in the Vitro home directory, contains the properties
that VIVO uses while running.
</p>
<p>
If you are building to <code>deploy</code> to Tomcat (as with previous releases),
then <code>build.properties</code> must contain these properties:
<ul>
<li><code>vitro.core.dir</code></li>
<li><code>webapp.name</code></li>
<li><code>tomcat.home</code></li>
<li><code>vitro.home</code> <em>-- note that this was <code>vitro.home.directory</code>
in previous releases</em></li>
</ul>
</p>
<p>
If you are building to <code>distribute</code>, the <code>build.properties</code>
file requires only these properties:
<ul>
<li><code>vitro.core.dir</code></li>
<li><code>webapp.name</code></li>
</ul>
</p>
<h4 id="solr_insecure">Solr is no longer secured</h4>
<p>
In previous releases, Solr was deployed to Tomcat with a <code>RemoteAddrValve</code>
that would only permit access from certain IP addresses.
Acceptable IP addresses were those which matched the regular expression pattern in
the <code>vitro.local.solr.ipaddress.mask</code> property.
</p>
<p>
This has been removed because:
<ul>
<li>It caused repeated problems for sites who were experimenting with VIVO.</li>
<li>It was not standards-based, but specific to Tomcat.</li>
<li>It was redundant. Production instances of VIVO are
usually hidden behind a firewall and accessed through an Apache Http server.</li>
</ul>
</p>
<p>
Sites that need to secure Solr are now left to their own devices.
</p>
<h4 id="log4j_properties">Log4J properties file renamed</h4>
<p>
In previous releases, the properties file for the VIVO logging system
was called <code>default.log4j.properties</code>. In release 1.6, this
file has been renamed to <code>log4j.properties</code>. This is so the
developers and implementers will know where to look for the file.
</p>
<p>
Note that <code>debug.log4j.properties</code>, if present, will still
override the default.
</p>
<h4 id="tabMenu">Property groups now displayed in a tab format, including a "View All" tab</h4>
<p>
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.
</p>
<h4 id="sparqlDataGetters">Class-specific SPARQL Query Data Getters</h4>
<p>
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:
<code>https://wiki.duraspace.org/display/VIVO/Enriching+VIVO+Content+Using+SPARQL+Query+Data+Getters</code>.
</p>
<h4 id="foafPersonTemplate">The foaf:Person template has been re-located.</h4>
<p>
The template individual--foaf-person.ftl has been moved to the "templates" subdirectory in the wilma
theme directory (vivo/themes/wilma/templates). If your installation has a customized version of
individual--foaf-person.ftl, ensure that it is located in the templates subdirectory in your installation's
theme directory or, if your installation does not have it's own theme directory, in the
<code>themes/wilma/templates subdirectory</code>.
</p>
<h4 id="multiple">Multiple foaf:Person Profile Pages</h4>
<p>
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. <strong>This web service is not included with the VIVO software.</strong> 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:
<code>https://wiki.duraspace.org/display/VIVO/Multiple+foaf%3APerson+Profile+Pages</code>.
</p>
<h4 id="homePage">Home Page Re-design</h4>
<p>
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, <a href="#optionalMap">optionally</a> a global map showing researchers'
areas of geographic focus.
</p>
<h4 id="rdffiles">Auto-loaded RDF files move to the Home directory</h4>
<p>
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.
</p>
<p>
If you have modified these RDF files, or added files of your own, you must adjust to
the new locations accordingly.
</p>
<h5>Old locations of RDF files</h5>
<pre>/WEB-INF/ontologies/app/application.owl
/WEB-INF/ontologies/app/aboutPage.n3
/WEB-INF/ontologies/app/menu.n3
/WEB-INF/ontologies/app/profilePageType.n3
/WEB-INF/ontologies/app/loadedAtStartup/displayModelListViews.rdf
/WEB-INF/ontologies/app/loadedAtStartup/homePageDataGetters.n3
/WEB-INF/ontologies/app/loadedAtStartup/localeSelectionGUI.n3
/WEB-INF/ontologies/app/loadedAtStartup/vivoListViewConfig.rdf
/WEB-INF/ontologies/app/loadedAtStartup/vivoOrganizationDataGetters.n3
/WEB-INF/ontologies/app/loadedAtStartup/vivoSearchProhibited.n3
/WEB-INF/ontologies/app/menuload/displayTBOX.n3
/WEB-INF/ontologies/app/menuload/displayDisplay.n3
/WEB-INF/init-data/initialSiteConfig.rdf
/WEB-INF/ontologies/user/abox/geopolitical.ver1.1-11-18-11-individual-labels.rdf
/WEB-INF/ontologies/user/abox/vocabularySource-labels.n3
/WEB-INF/ontologies/user/tbox/vitro-0.7-annotations.rdf
/WEB-INF/ontologies/user/tbox/geopolitical-ver1.1-11-18-11-annotations.rdf
/WEB-INF/ontologies/user/tbox/scires-1.5-annotations.rdf
/WEB-INF/ontologies/user/tbox/vivo-core-1.5-annotations.rdf
/WEB-INF/ontologies/user/tbox/isDefinedBy-1.5-annotations.rdf
/WEB-INF/ontologies/user/applicationMetadata/propertygroups.rdf
/WEB-INF/ontologies/user/applicationMetadata/classgroups.rdf
/WEB-INF/filegraph/abox/us-states.rdf
/WEB-INF/filegraph/abox/geopolitical.abox.ver1.1-11-18-11.owl
/WEB-INF/filegraph/abox/academicDegree.rdf
/WEB-INF/filegraph/abox/documentStatus.owl
/WEB-INF/filegraph/abox/continents.n3
/WEB-INF/filegraph/abox/vocabularySource.n3
/WEB-INF/filegraph/abox/dateTimeValuePrecision.owl
/WEB-INF/filegraph/tbox/vitroPublic.owl
/WEB-INF/filegraph/tbox/vivo-dcterms-1.5.owl
/WEB-INF/filegraph/tbox/scires-1.5.owl
/WEB-INF/filegraph/tbox/vivo-core-1.5.owl
/WEB-INF/filegraph/tbox/vivo-c4o-1.5.owl
/WEB-INF/filegraph/tbox/geopolitical.tbox.ver1.1-11-18-11.owl
/WEB-INF/filegraph/tbox/vivo-fabio-1.5.owl
/WEB-INF/filegraph/tbox/vivo-skos-1.5.owl
/WEB-INF/filegraph/tbox/vivo-event-1.5.owl
/WEB-INF/filegraph/tbox/vivo-foaf-1.5.owl
/WEB-INF/filegraph/tbox/vitro-0.7.owl
/WEB-INF/filegraph/tbox/vivo-pws-1.5.owl
/WEB-INF/filegraph/tbox/isDefinedBy-1.5.owl
/WEB-INF/filegraph/tbox/vivo-dcelements-1.5.owl
/WEB-INF/filegraph/tbox/vivo-bibo-1.5.owl</pre>
<h5>New locations of RDF files</h5>
<pre>rdf/display/firsttime/aboutPage.n3
rdf/display/firsttime/application.owl
rdf/display/firsttime/menu.n3
rdf/display/firsttime/profilePageType.n3
rdf/display/everytime/displayModelListViews.rdf
rdf/display/everytime/homePageDataGetters.n3
rdf/display/everytime/localeSelectionGUI.n3
rdf/display/everytime/vivoListViewConfig.rdf
rdf/display/everytime/vivoOrganizationDataGetters.n3
rdf/display/everytime/vivoSearchProhibited.n3
rdf/displayTbox/everytime/displayTBOX.n3
rdf/displayDisplay/everytime/displayDisplay.n3
rdf/applicationMetadata/firsttime/classgroups.rdf
rdf/applicationMetadata/firsttime/initialSiteConfig.rdf
rdf/applicationMetadata/firsttime/propertygroups.rdf
rdf/abox/firsttime/geopolitical.ver1.1-11-18-11-individual-labels.rdf
rdf/abox/firsttime/vocabularySource-labels.n3
rdf/abox/filegraph/abox/academicDegree.rdf
rdf/abox/filegraph/abox/continents.n3
rdf/abox/filegraph/abox/dateTimeValuePrecision.owl
rdf/abox/filegraph/abox/documentStatus.owl
rdf/abox/filegraph/abox/geopolitical.abox.ver1.1-11-18-11.owl
rdf/abox/filegraph/abox/us-states.rdf
rdf/abox/filegraph/abox/vocabularySource.n3
rdf/tbox/firsttime/geopolitical-ver1.1-11-18-11-annotations.rdf
rdf/tbox/firsttime/isDefinedBy-1.5-annotations.rdf
rdf/tbox/firsttime/scires-1.5-annotations.rdf
rdf/tbox/firsttime/vitro-0.7-annotations.rdf
rdf/tbox/firsttime/vivo-core-1.5-annotations.rdf
rdf/tbox/filegraph/tbox/geopolitical.tbox.ver1.1-11-18-11.owl
rdf/tbox/filegraph/tbox/isDefinedBy-1.5.owl
rdf/tbox/filegraph/tbox/scires-1.5.owl
rdf/tbox/filegraph/tbox/vitro-0.7.owl
rdf/tbox/filegraph/tbox/vitroPublic.owl
rdf/tbox/filegraph/tbox/vivo-bibo-1.5.owl
rdf/tbox/filegraph/tbox/vivo-c4o-1.5.owl
rdf/tbox/filegraph/tbox/vivo-core-1.5.owl
rdf/tbox/filegraph/tbox/vivo-dcelements-1.5.owl
rdf/tbox/filegraph/tbox/vivo-dcterms-1.5.owl
rdf/tbox/filegraph/tbox/vivo-event-1.5.owl
rdf/tbox/filegraph/tbox/vivo-fabio-1.5.owl
rdf/tbox/filegraph/tbox/vivo-foaf-1.5.owl
rdf/tbox/filegraph/tbox/vivo-pws-1.5.owl
rdf/tbox/filegraph/tbox/vivo-skos-1.5.owl</pre>
<p>
If you are using a three-tier build process, you will need to add a single line
to the build script so the RDF files will be merged properly across the tiers. So this:
<pre>&lt;patternset id="appbase.patterns"&gt;
&lt;include name="src/**/*" /&gt;
&lt;include name="lib/**/*" /&gt;
&lt;include name="test/**/*" /&gt;
&lt;include name="themes/**/*" /&gt;
&lt;include name="config/*.properties" /&gt;
&lt;include name="config/*.txt" /&gt;
&lt;include name="config/jarlist/*.txt" /&gt;
&lt;include name="config/solr/*" /&gt;
&lt;include name="context.xml" /&gt;
&lt;/patternset&gt;</pre>
becomes this:
<pre>&lt;patternset id="appbase.patterns"&gt;
&lt;include name="src/**/*" /&gt;
&lt;include name="lib/**/*" /&gt;
&lt;include name="rdf/**/*" /&gt;
&lt;include name="test/**/*" /&gt;
&lt;include name="themes/**/*" /&gt;
&lt;include name="config/*.properties" /&gt;
&lt;include name="config/*.txt" /&gt;
&lt;include name="config/jarlist/*.txt" /&gt;
&lt;include name="config/solr/*" /&gt;
&lt;include name="context.xml" /&gt;
&lt;/patternset&gt;</pre>
</p>
<h4 id="language">Support for additional languages</h4>
<p>
VIVO 1.6 includes limited support for other languages, in addition to American English.
This limited support is described as <em>read-only</em> support on <em>public-facing</em>
pages.
</p>
<p>
<em>Read-only</em> 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.
</p>
<p>
<em>Public-facing</em> means that most of the pages used for site adminstration
are only presented in American English.
</p>
<p>
These two pages in the VIVO Wiki describe how to
<a href="https://wiki.duraspace.org/display/VIVO/Building+a+multi-language+VIVO+instance">
Build VIVO with multiple languages</a> and how to
<a href="https://wiki.duraspace.org/display/VIVO/Adding+a+language+to+VIVO">
Add a new language to VIVO</a>.
</p>
<h4 id="BOGUS">ANYTHING ELSE?</h4>
<p>
</p>
</li>
<li>
<h4 id="browsers">Supported Browsers</h4>
<p>
For this release, the following browsers are supported.
BOGUS IS THIS LIST CURRENT?
</p>
<p>
Mac:
</p>
<ul>
<li>Chrome 8.0.552.237</li>
<li>FireFox 3.6.13</li>
<li>Opera 10.6.2</li>
<li>Safari 5.0.3</li>
</ul>
<p>
PC:
</p>
<ul>
<li>Chrome 8.0.552.273</li>
<li>FireFox 10.0.2</li>
<li>Internet Explorer 7, 8, 9</li>
<li>Opera 10.6.2</li>
</ul>
</li>
</ul>
<h3 id="upgrade_process">III. Upgrade Instructions</h3>
<p>
1. Download the new distribution file and unpack it into a new
source directory.
</p>
<p>
2. Separate your existing <code>deploy.properties</code> file into two files,
as described below. Store the new <code>build.properties</code> file in
the top level of the VIVO distribution directory. Store the new <code>runtime.properties</code>
file in your VIVO home directory.
<br>
</p>
<table border='1' bordercolor="#CCCCCC" cellspacing="5">
<tbody>
<tr>
<th width="50%">
Properties in <code>build.properties</code>
</th>
<th>
Properties in <code>runtime.properties</code>
</th>
</tr>
<tr class="odd_row blue">
<td>
<code>vitro.core.dir</code><br>
<code>vitro.home</code><br>
<code>tomcat.home</code><br>
<code>webapp.name</code><br>
</td>
<td>
All other properties from <code>deploy.properties</code>
</td>
</tr>
<tr>
<td colspan="2">
<em>Note that <code>vitro.home</code> replaces <code>vitro.home.directory</code></em>
<br>
<em>Note that <code>vitro.local.solr.ipaddress.mask</code> is no longer used.</em>
</td>
</tr>
</tbody>
</table>
<br>
<p>
If you prefer, you may start with <code>example.build.properties</code>
and <code>example.runtime.properties</code>, make copies,
and edit them to suit your installation. Remember, the <code>runtime.properties</code> file
goes into your VIVO home directory.
</p>
<p>
The properties below are new to <code>build.properties</code>. They are optional,
so you need not add them unless you want a value other than the default.
</p>
<p>
<!-- runtime.properties table from install.html -->
</p>
<table border='1' bordercolor="#CCCCCC" cellspacing="5">
<tbody>
<tr>
<th>
Property Name
</th>
<th>
Example Value
</th>
</tr>
<tr>
<td colspan="2">
Languages (in addition to American English) that will be built into your
VIVO site. The languages must be found in the
<code>languages</code> directory of the VIVO distribution.
See <a href="https://wiki.duraspace.org/display/VIVO/Building+a+multi-language+VIVO+instance">
the VIVO Wiki</a> for more information.
</td>
</tr>
<tr class="odd_row blue">
<td>
languages.addToBuild
</td>
<td>
es_MX
</td>
</tr>
</tbody>
</table>
<p>
The properties below are new to <code>runtime.properties</code>. They are optional,
so you need not add them, unless you want a value other than the default.
</p>
<p>
<!-- runtime.properties table from install.html -->
</p>
<table border='1' bordercolor="#CCCCCC" cellspacing="5">
<tbody>
<tr>
<th>
Property Name
</th>
<th>
Example Value
</th>
</tr>
<tr>
<td colspan="2">
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:
<a href="https://wiki.duraspace.org/display/VIVO/Use+HTTP+caching+to+improve+performance">
Use HTTP caching to improve performance </a>
</td>
</tr>
<tr class="odd_row blue">
<td>
http.createCacheHeaders
</td>
<td>
true
</td>
</tr>
<tr>
<td colspan="2">
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.
</td>
</tr>
<tr class="odd_row blue">
<td>
languages.forceLocale
</td>
<td>
en_US
</td>
</tr>
<tr>
<td colspan="2">
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.
</td>
</tr>
<tr class="odd_row blue">
<td>
languages.selectableLocales
</td>
<td>
en, es, fr_FR
</td>
</tr>
<tr>
<td colspan="2">
<b>For developers only.</b>
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 <code>false</code>, which
means that a cached copy of each template will be used for 60 seconds
before the disk is checked for a new version.
<br/><b>Setting this option to "true" slows down VIVO performance.</b>
</td>
</tr>
<tr class="odd_row blue">
<td>
developer.defeatFreemarkerCache
</td>
<td>
false
</td>
</tr>
<tr>
<td colspan="2">
<b>For developers only.</b>
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 <code>false</code>, which means that the language file is
read when VIVO starts up, or when a new theme is selected.
<br/><b>Setting this option to "true" slows down VIVO performance.</b>
</td>
</tr>
<tr class="odd_row blue">
<td>
developer.defeatI18nCache = true
</td>
<td>
false
</td>
</tr>
<tr>
<td colspan="2">
<b>For developers only.</b>
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 <code>false</code>.
<br/><b>Setting this option to "true" slows down VIVO performance.</b>
</td>
</tr>
<tr class="odd_row blue">
<td>
developer.insertFreemarkerDelimiters = true
</td>
<td>
false
</td>
</tr>
<tr>
<td colspan="2" id="optionalMap">
On the VIVO home page, display a global map highlighting the geographical focus
of foaf:person individuals. The default is <code>enabled</code>.
</td>
</tr>
<tr class="odd_row blue">
<td>
homePage.geoFocusMaps = enabled
</td>
<td>
enabled
</td>
</tr>
<tr>
<td colspan="2">
<b>MultiViews for foaf:person profile pages.</b>
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.
<b>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.</b>
The default is <code>disabled</code>.
</td>
</tr>
<tr class="odd_row blue">
<td>
MultiViews.profilePageTypes=disabled
</td>
<td>
disabled
</td>
</tr>
</tbody>
</table>
<p>
3. Apply any previous changes you have made to the new source
directory.
</p>
<blockquote>
<strong>Special notes regarding source files</strong>
<ul>
<li>
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.
</li>
<li>
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.
</li>
<li>
NIH-funded VIVO implementations will need to apply the
Google Analytics Tracking Code (GATC) to <code>googleAnalytics.ftl</code>
in the theme:<pre>[new_source_directory]/themes/[theme_dir]/templates/googleAnalytics.ftl</pre>
A sample <code>googleAnalytics.ftl</code> is 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 <a href="https://confluence.cornell.edu/display/ennsrd/Google+Analytics+for+UI">VIVO
Google
Analytics
wiki
page</a>.
</li>
</ul>
</blockquote>
<p>
4. Apply any previous changes you have made to the RDF initialization files.
See the section on the <a href="#rdffiles">Auto-loaded RDF files</a>
above for more details.
</p>
<p>
5. Stop Apache Tomcat and from your VIVO source directory, run
ant
by typing: <code>ant all</code>
</p>
<p>
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.<pre>INFO: Server startup in XXXXX ms</pre>
</p>
<p>
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".
</p>
<p>
8. Review and save aside the knowledge base migration logs.
The knowledge base migration process described in the next section will generate logs.
These logs will be overwritten if you redeploy the VIVO application (but not if you restart tomcat), and since
they may be a useful reference if questions come up about your 1.6 VIVO data after deployment,
you should save them aside.
The logs are created in the Tomcat <code>webapps/vivo/WEB-INF directory</code>:
</p>
<dl>
<dt>
<code>ontologies/update/logs/knowledgeBaseUpdate.(timestamp).log</code>
</dt>
<dd>
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.
</dd>
</dl>
<dl>
<dt>
<code>ontologies/update/logs/knowledgeBaseUpdate.(timestamp).error.log</code>
</dt>
<dd>
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.
</dd>
</dl>
<p>
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:
<ol>
<li>
Once the VIVO application is running, go to the Site Admin page and click the "Ingest Tools"
link under Advanced Data Tools.
</li>
<li>
From the Ingest Menu click the "Manage Jena Tools" link, and then click the "RDB Models" button.
</li>
<li>
Locate the "vitro-kb-displayMetadata" model and click the "load RDF data" button.
</li>
<li>
Click the "Browse" button to upload the file from your computer and select the aboutPage.n3 file
located here in the VIVO source: <code>productMods/WEB-INF/ontologies/app/aboutPage.n3</code>.
</li>
<li>
Select N3 as the file type from the drop-down list and then click the "Load Data" button.
</li>
<li>
Restart tomcat.
</li>
</ol>
</p>
<p>
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.
</p>
<h3 id="#kbm">IV. Knowledge Base Migration</h3>
<p>
Changes to the VIVO core ontology may require corresponding
modifications to the knowledge base instance data and ontology annotations.
When VIVO first starts up following the upgrade, it will
initiate a process to examine the knowledge base and apply necessary
changes. The knowledge base migration process for release 1.6 will make
the following types of changes:
</p>
<dl>
<dt>
BOGUS CHANGES
</dt>
</dl>
<dl>
<dt>
Annotation property default values
</dt>
<dd>
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.
<br>
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.
</dd>
</dl>
<p>
In addition to the logs described in <strong>step 8</strong> of the <a href="#upgrade_process">previous section</a>, the knowledge base migration
process will log copies of all additions and deletions that were made to the knowledge base in the following files:
</p>
<dl>
<dt>
<code>webapps/vivo/WEB-INF/ontologies/update/changedData/removedData.n3</code>
</dt>
<dd>
An N3 file containing all the statements that were removed from the knowledge base.
</dd>
</dl>
<dl>
<dt>
<code>webapps/vivo/WEB-INF/ontologies/update/changedData/addedData.n3</code>
</dt>
<dd>
An N3 file containing all the statements that were added to the knowledge base.
</dd>
</dl>
<h3 id="termsofuse">V. Review the VIVO Terms of Use</h3>
<p>
VIVO comes with a "Terms of Use" statement linked from the footer. The "Site Name"
you assign in the "Site Information" form under the <strong>Site Admin</strong>
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:<pre>[vivo_source_dir]/vitro-core/webapp/web/templates/freemarker/body/termsOfUse.ftl</pre>
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.
</p>
<h3 id="nextsteps">Next Steps</h3>
<p>
Now that you have VIVO up and running, please refer to the
<a href="https://wiki.duraspace.org/display/VIVO/Site+Administrator+Guide">Site Administrator's Guide</a>
for information about its operation.
</p>
</div>
<!-- #wrapper-content -->
<div id="footer" role="contentinfo">
<p class="copyright">
<small>
&copy;2013 All Rights Reserved
</small>
| Powered
by <a class="powered-by-vivo" href="http://vivoweb.org" target="_blank"><strong>VIVO</strong></a>
</p>
<div id="nav" role="navigation">
<ul id="footer-nav" role="list">
<li role="listitem">
<a href="http://vivoweb.org/about">About</a>
</li>
<li role="listitem">
<a href="http://vivoweb.org/contact">Contact Us</a>
</li>
<li role="listitem">
<a href="http://www.vivoweb.org/support" target="blank">Support</a>
</li>
</ul>
</div>
</div>
<!-- #footer -->
</div>
</body>
</html>