VIVO Release 1 v1.3 Upgrade Guide
+VIVO Release 1 V1.3 Upgrade Guide
- July 22, 2011 - Upgrading from Release 1 v1.2 to Release 1 v1.3 + July 28, 2011 - Upgrading from Release 1 V1.2 to Release 1 V1.3-
@@ -33,77 +33,90 @@
at VIVOweb.org
- @@ -127,11 +140,12 @@
- - Ontology + Ontology Changes +
- + Review the VIVO Terms of Use +
- - DO NOT reinstall MySQL or recreate the MySQL database. Please + DO NOT reinstall MySQL or recreate the MySQL database. Please ensure that you back-up the MySQL database. Also note that VIVO 1.2 - will not run on older versions of MySQL that may have worked with - 1.1.1. Be sure to run VIVO 1.2 with MySQL 5.1 or higher. Using - unsupported versions may result in strange error messages related to + will not run on older versions of MySQL that may have worked with + 1.1.1. Be sure to run VIVO 1.2 with MySQL 5.1 or higher. Using + unsupported versions may result in strange error messages related to table formatting or other unexpected problems.
- It is not necessary to add RDF data.
- - First-time login of the administrator account after the + First-time login of the administrator 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. With V1.3 there is also a new root user. Please see the + process is complete will use the password previously set, NOT the + default password used on the first login after the initial + installation. With V1.3 there is also a new root user. Please see the section on Authorization changes for more information. @@ -236,16 +253,15 @@ below for more information.
- If you need to do a fresh install, please consult the VIVO Release
- 1 v1.3 Installation Guide found on vivoweb.org
+ If you need to do a fresh install, please consult the VIVO Release V1.3 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 (there are no new hardware
or software requirements for V1.3).
Release Announcement for V1.3
- VIVO Release 1.3 incorporates changes to - the search indexing, user accounts, menu management, ontology, and - visualizations. + VIVO Release V1.3 incorporates changes to the search + indexing, user accounts, menu management, ontology, and visualizations, and begins + integration of VIVO Harvester functions with VIVO's own ingest tools.Search
- VIVO 1.3 will feature notable improvements to the local search, - primarily to improve relevance ranking but also to boost the influence - of semantic relationships in the search. This will improve recall by - including text from related resources (e.g., adding a person's grant - and publication titles to his or her search entry) and by boosting - overall relevance ranking based on the number and nature of connections - from one individual to others. -- VIVO is now using Apache Solr (http://lucene.apache.org/solr/) in place - of Apache Lucene to improve indexing and faceting of search results. - The migration to Solr also aligns the local search with the VIVO - multi-site search site under development for release prior to the 2011 - VIVO Conference. -
+
+ VIVO V1.3 will feature notable improvements to the local search, primarily to improve relevance + ranking but also to boost the influence of semantic relationships in the search. This will + improve recall by including text from related resources (e.g., adding a person's grant and + publication titles to his or her search entry) and by boosting overall relevance ranking + based on the number and nature of connections from one individual to others. +
++ VIVO is now using Apache Solr (http://lucene.apache.org/solr/) in place of Apache Lucene to + improve indexing and faceting of search results. The migration to Solr also aligns the + local search with the VIVO multi-site search site under development for release prior to + the 2011 VIVO Conference. +
Authorization
- Release 1.3 provides an entirely new model of authorization within the - VIVO application to allow more granular control over system - configuration and editing. The first phase of the new user account - interface is included in V1.3. This interface provides a user search, a - root acount, and password reset functionality where the password gets - emailed to the user. The next phase will provide the ability to create - new roles. -+
+ Release V1.3 provides an entirely new model of authorization within the + VIVO application to allow more granular control over system + configuration and editing. The first phase of the new user account + interface is included in V1.3. This interface provides a user search, a + root acount, and password reset functionality where the password gets + emailed to the user. The next phase will provide the ability to create + new roles. +
Menu management
- The menus across the top of the site (Home, People, Organizations, - Research, Events) can now be managed in a web form instead of editing - an RDF file. In addition to making site management much easier, - form-based editing also allows more control over what classes of data - are displayed and provides a mechanism to limit certain menu pages to - content identified as internal to the institution. --
FreeMaker template improvements
- While less directly visible to the public, version 1.3 also includes - additional changes focused directly on supporting open source community - involvement in extending and customizing VIVO. The development team - began a year ago to transition VIVO's code base away from Java Server - Pages to the FreeMarker page templating system that much more cleanly - separates internal application programming logic from page display. -+
+ The menus across the top of the site (Home, People, Organizations, + Research, Events) can now be managed in a web form instead of editing + an RDF file. In addition to making site management much easier, + form-based editing also allows more control over what classes of data + are displayed and provides a mechanism to limit certain menu pages to + content identified as internal to the institution. +
+FreeMarker template improvements
++ While less directly visible to the public, V1.3 also includes + additional changes focused directly on supporting open source community + involvement in extending and customizing VIVO. The development team + began a year ago to transition VIVO's code base away from Java Server + Pages to the FreeMarker page templating system that much more cleanly + separates internal application programming logic from page display. +
Visualization
- The visualization team has implemented a Map of Science visualization, - which allows users to visually explore the scientific strengths of a - university, school, department, or person in the VIVO instance. Users - will be able to see where an organization or person's interests lay - across 13 major scientific disciplines or 554 sub-disciplines, and will - be able to see how these disciplines and sub-disciplines interrelate - with one another on the map of science. Wireframes and design - documentation for upcoming enhanced versions of the Map of Science - visualization have already been developed; the Map of Science - visualization will most likely be in the form of a PDF that a user can - download. -- Several visualization also now provide a caching feature that improves - performance after the initial processing. -
+
+ The visualization team has implemented a Map of Science visualization, + which allows users to visually explore the scientific strengths of a + university, school, department, or person in the VIVO instance. Users + will be able to see where an organization or person's interests lay + across 13 major scientific disciplines or 554 sub-disciplines, and will + be able to see how these disciplines and sub-disciplines interrelate + with one another on the Map of Science. Wireframes and design + documentation for upcoming enhanced versions of the Map of Science + visualization have already been developed; the Map of Science + visualization will most likely be in the form of a PDF that a user can + download. +
++ Several visualizations also now provide a caching feature that improves + performance after the initial processing. +
QR Codes
- Pages for people in VIVO have the option of displaying QR codes. -+
+ Pages for people in VIVO now have an icon for displaying QR codes to allow + capturing names and available contact information on mobile devices. +
+Harvester Integration
++ VIVO sites have the option with Release 1.3 of coordinating the configuration + of VIVO and the Harvester to enable many Harvester functions to be initiated + from the VIVO Ingest Tools menu in support of more unified and centralized + management for data ingest. +
Ontology changes
Linked open data
- Responses to linked data requests have been enhanced to include - additional context about any individual, in working toward a goal of - being able to provide all the data in a person's profile available as - RDF via a single web request. -+
+ Responses to linked data requests have been enhanced to include + additional context about any individual, in working toward a goal of + being able to provide all the data in a person's profile available as + RDF via a single web request. +
Upgrade process for V1.3
I. Before Performing the Upgrade
@@ -209,22 +226,22 @@
II. Noteworthy Changes -
-i. Triple store changes
+ II. Noteworthy Changes
+ i. Triple store
VIVO 1.3 now requires you to use Jena's SPARQL database (SDB) for - the triple store technology. Jena's legacy relational database - store (RDB) was used by VIVO 1.1.1 and earlier. Both SDB and RDB - were available in VIVO 1.2 and 1.2.1. It is required that you + the triple store technology. Jena's legacy relational database + store (RDB) was used by VIVO 1.1.1 and earlier. Both SDB and RDB + were available in VIVO 1.2 and 1.2.1. It is required that you move your triple store to SDB while still at V1.2.
@@ -254,26 +270,26 @@ allows VIVO installations to display data from large RDF models while requiring only a small amount of server memory to run the application. There is a tradeoff in response time: pages may take slightly longer to - load in SDB mode, and performance will depend on the configuration + load in SDB mode, and performance will depend on the configuration parameters of the database server. Additionally, advanced OWL reasoning - (not enabled by default in either mode) is not possible in SDB mode. - With SDB, only the default set of inferences (inferred rdf:type - statements) are generated, and they are generated as soon as data is + (not enabled by default in either mode) is not possible in SDB mode. + With SDB, only the default set of inferences (inferred rdf:type + statements) are generated, and they are generated as soon as data is edited rather than in a background process.
- A conversion from RDB to SDB mode can take a number of hours to + A conversion from RDB to SDB mode can take a number of hours to complete if the installation contains a large amount of RDF data - (roughly a million triples or more). You can start the conversion - process in the background while the RDB system is running. This will - reduce the delay in initial startup after the application is redeployed + (roughly a million triples or more). You can start the conversion + process in the background while the RDB system is running. This will + reduce the delay in initial startup after the application is redeployed with deploy.properties set for SDB. Note that it is important not to edit any data anywhere in the application while this background conversion is running.
To start the SDB conversion, log in as a system administrator and - request /sdbsetup (For example, if your VIVO is installed at + request /sdbsetup (for example, if your VIVO is installed at http://vivo.myuniversity.edu/ you would type http://vivo.myuniversity.edu/sdbsetup into your browser).
@@ -283,37 +299,35 @@During the course of the SDB setup, which may take several hours on - a large database, subsequent requests to /sdbsetup will display a + a large database, subsequent requests to /sdbsetup will display a message that the operation is still in progress. When a request for - this page shows a message that the SDB setup has completed - successfully, shut down Tomcat, set deploy.properties to SDB mode, - redeploy, and restart Tomcat. VIVO will now be running from the SDB + this page shows a message that the SDB setup has completed + successfully, shut down Tomcat, set deploy.properties to SDB mode, + redeploy, and restart Tomcat. VIVO will now be running from the SDB store.
-
ii. Theme changes
+ii. Theme
The vivo-basic theme was deprecated with VIVO V1.2 and is no longer - present in the V1.3 release as it does not support V1.2 or V1.3 - features. It is highly recommended that you use the wilma theme or - modify the wilma theme for branding or to create a custom look and + present in the V1.3 release as it does not support V1.2 or V1.3 + features. It is highly recommended that you use the wilma theme or + modify the wilma theme for branding or to create a custom look and feel. Please see the Site Administration Guide for more information about customizing your theme.
iii. Template changes
+iii. Template
-
- The
@@ -333,8 +347,8 @@${stylesheets},${scripts}, - and${headScripts}-add()- methods now take the - full tag as an argument. - This will require a change to all calls to these methods in the + The${stylesheets},${scripts}, + and${headScripts} add()+ methods now take the full tag as an argument. + This will require a change to all calls to these methods in the templates. This change allows for specification of attributes such asmediadirectly in the tag. For example: -
The
addFromTheme()- methods of the${stylesheets},${scripts}, - and${headScripts}+ methods of the${stylesheets},${scripts}, + and${headScripts}objects have been deleted. Substitute as shown in the preceding example.
@@ -346,7 +360,7 @@
v. List view changes
+v. List view
<query-base>
and <query-collated>
@@ -356,20 +370,19 @@
v. Authorization changes
+v. Authorization
- In release 1.3, the VIVO authorization system has some extensive + In V1.3, the VIVO authorization system has some extensive changes. In summary, these are:
- Each user will have a user account, even if the user logs in - by - Shibboleth or some other external authentication system. + with Shibboleth or some other external authentication system.
- - E-mail is used to notify user's when an account is created for + E-mail is used to notify users when an account is created for them, or when an administrator edits their account.
-
@@ -385,33 +398,28 @@
-
- With release 1.3, each authenticated - user will have a user + With V1.3, each authenticated user will have a user account. If someone logs in using an external authentication system, and no user account matches their external login credentials, an account will be created.
- The user will be prompted to enter - information for the - account - being created: first name, last name, and e-mail address. + The user will be prompted to enter information for the + account being created: first name, last name, and e-mail address.
-
b. E-mail address - becomes an important - part - of User Accounts
+ becomes an important part of User Accounts-
- Prior to release 1.3, each user account was identified by a - Username field. This field was labeled as "E-mail address" on some - pages in VIVO, but no mail was ever sent. In release 1.3, this has - changed, so the e-mail address is fully used, both for identification + Prior to V1.3, each user account was identified by a + Username field. This field was labeled as "E-mail address" on some + pages in VIVO, but no mail was ever sent. In V1.3, this has + changed, so the e-mail address is fully used, both for identification and for communication with the user.
@@ -426,54 +434,48 @@
-
- Prior to release 1.3, the Username field (also referred to as + Prior to V1.3, the Username field (also referred to as 'e-mail address') was used for several purposes:
- - Idenfiying the user account. + Idenfiying the user account
- Part of the user's credentials when logging in (along with - a - password). + a password)
- Connecting the user account to an external authentication - system, like Shibboleth or CUWebAuth. + system, like Shibboleth or CUWebAuth
- - Connecting the user account to a personal Profile page. + Connecting the user account to a personal Profile page
- With release 1.3, these functions are handled by two separate + With V1.3, these functions are handled by two separate fields called EmailAddress field and ExternalAuthId.
- EmailAddress is used when logging in (along with a - password). + password)
- EmailAddress is used to send notifications to the user - about - changes to his/her account (see below). + about changes to his/her account (see below)
- The ExternalAuthId is used when logging in using an - external - authentication system. + external authentication system
-
The ExternalAuthId is used to connect the user account to
- a
- personal Profile page.
+ a personal Profile page
Note: - With release 1.3, the - ExternalAuthId can now be matched against either an untyped literal or - a string literal in the Profile page. + With V1.3, the ExternalAuthId can now be matched against either an untyped literal or a string literal in the Profile page.
-
- If you are upgrading to VIVO release 1.3 from an existing - VIVO + If you are upgrading to VIVO V1.3 from an existing + VIVO installation, the user accounts in your system will be migrated into - the new data structures. When migrating an account, both the - EmailAddress field and the ExternalAuthId field will be set to the - value of the Username field in the old account. The new account should + the new data structures. When migrating an account, both the + EmailAddress field and the ExternalAuthId field will be set to the + value of the Username field in the old account. The new account should behave as the old account did.
When creating a new user account, or editing an existing one, the system requires that your e-mail address be in a valid form, like
somebody@somewhere.edu. You - should + should plan - for - this - as - part of your migration to release 1.3 + for + this + as + part of your migration to V1.3
-
- With release 1.3, VIVO users receive e-mail notifications + With V1.3, VIVO users receive e-mail notifications when an account is created or modified for them or by them.
@@ -538,11 +540,11 @@Note: - when creating the account, + when creating the account, the - administrator may indicate that it will only be used with an external - authentication system like Shibboleth or CUWebAuth. In this case, the - account will not require a password, and the e-mail notification + administrator may indicate that it will only be used with an external + authentication system like Shibboleth or CUWebAuth. In this case, the + account will not require a password, and the e-mail notification message to the user will not provide a password link.
@@ -565,15 +567,15 @@
4. Disabling e-mail notificiation
+4. Disabling e-mail notification
-
- The e-mail notification relies on two configuration - properties:
email.smtpHost+ The e-mail notification relies on two configuration + properties:email.smtpHostandemail.replyTo. If either of these properties is missing or empty, VIVO will not attempt to send e-mail notifications to users. @@ -584,9 +586,9 @@If e-mail notifications are disabled, an administrator must - set - a password on each new account, since the user will have no way of - setting it. When the user logs in for the first time, VIVO will require + set + a password on each new account, since the user will have no way of + setting it. When the user logs in for the first time, VIVO will require them to change their password to one of their own choosing.
@@ -597,10 +599,10 @@
-
- Prior to release 1.3, each VIVO - installation was created with - a - default administrator's account. In release 1.3, there is no such + Prior to V1.3, each VIVO + installation was created with + a + default administrator's account. In V1.3, there is no such account. Instead, each VIVO installation will have a "root" account.
@@ -613,34 +615,34 @@ The password for this account is automatically set to
rootPassword, but - you + you will - be - required - to change the password the first time you log + be + required + to change the password the first time you log in.