VIVO Release 1 v1.3 Upgrade Guide

- July 22, 2011 - Upgrading from Release 1 v1.2 to Release 1 - v1.3 + July 22, 2011 - Upgrading from Release 1 v1.2 to Release 1 v1.3
    @@ -43,12 +42,99 @@ or software requirements for V1.3).

    Release Announcement for V1.3

    -

    - https://confluence.cornell.edu/x/3B4DCQ - get content from the wiki - page before final release. -
    -

    -

    Upgrade process for V1.3

    + VIVO Release 1.3 incorporates changes to + the search indexing, user + accounts, menu management, ontology, and visualizations. +
    +

    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. +
    +

    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. +
    +

    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. +
    +

    Visualization

    + The visualization team has implemented a Science Map 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 Science Map + visualization have already been developed; the Science Map + 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. +
    +

    QR Codes

    + Pages for people in VIVO have the option of displaying QR codes. +
    +

    Ontology changes

    +
      +
    • + support for certifications and licenses +
      • +
    • + expanded support for intellectual property (patents) (it was + there as stub before but didn't allow common things such as assignee + and issuer) +
      • +
    • + support for editorial, reviewing and organizing activities +
      • +
    • + expanded shared geographical instance data vocabulary to include + the 50 U.S. states +
      • +
    • + representing specific types of EducationalTraining: + PostdoctoralTraining, Internship, MedicalResidency +
      • +
    +

    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. +
    +
    +

    Upgrade process for V1.3

    1. @@ -92,14 +178,10 @@
    2. Each VIVO installation will have a - “root” account + 'root' account
    -
  • - Set Up SDB Store in the Background - (Optional) -

    • I. Before Performing the Upgrade

    @@ -123,8 +205,8 @@

    • - If you are still in RDB mode, it is required that you - move your triple store to SDB while still at V1.2 (see Triple Store + If you are still in RDB mode, it is required that you move your + triple store to SDB while still at V1.2 (see Triple Store info below). 
      @@ -144,7 +226,8 @@ 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. + installation. With V1.3 there is also a new root user. Please see the + section on Authorization changes for more information.
    • The first time Apache Tomcat starts up after the upgrade, it @@ -158,15 +241,15 @@ 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 move your triple store to SDB while still at V1.2. + 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.

      SDB mode caches only a fraction of the RDF data in memory. Most queries are issued directly against the underlying database. This 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 make take slightly longer + There is a tradeoff in response time: pages may take slightly longer to 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. @@ -176,15 +259,14 @@

      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 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. + 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 + 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 @@ -215,14 +297,14 @@ 2. Create a new deploy.properties using the same values as in your previous installation and set values for the new variables as described below (vitro.local.solr.url, vitro.local.solr.ipaddress.mask, - vitro.home.directory, - email.smptHost, email.replyTo, rootUser.emailAddress) + vitro.home.directory, email.smptHost, email.replyTo, + rootUser.emailAddress)

      - +
      @@ -324,14 +406,14 @@ Examples:
      • - vitro.local.solr.ipaddress.mask = 127\.0\.0\.1 + vitro.local.solr.ipaddress.mask = 127\.0\.0\.1
      • - vitro.local.solr.ipaddress.mask = - 127\.0\.0\.1,0:0:0:0:0:0:0:1 + vitro.local.solr.ipaddress.mask = + 127\.0\.0\.1,0:0:0:0:0:0:0:1
      • - vitro.local.solr.ipaddress.mask = 169.254.* + vitro.local.solr.ipaddress.mask = 169.254.*
      @@ -650,9 +732,7 @@ implementation sites and a copy of your institution's tracking code, see the VIVO Google - Analytics - wiki - page. + Analytics wiki page.
    • If you had used the vivo/contrib/FLShibboleth @@ -671,7 +751,7 @@ that modification.

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

      6. Start Apache Tomcat and log in to VIVO. @@ -790,14 +870,14 @@

      • - The ${stylesheets}, ${scripts}, and ${headScripts} + 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 as media - directly - in the tag. For example: + 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 as media + directly in the tag. For + example:

        1.2: ${stylesheets.add("/css/individual/individual.css")} @@ -807,53 +887,48 @@

        Note the inclusion of ${urls.base} - in the 1.3 - example. - The add() - method no longer prefixes the context path to - the url, so the full - url must be specified in the tag. + in the 1.3 + example. The add() + method no longer prefixes the context + path to the url, so the full url must be specified in the tag.

      • The addFromTheme() - methods of the ${stylesheets},${scripts}, and${headScripts} - objects have been deleted. Substitute - as shown in the - preceding example. + methods of the ${stylesheets},${scripts}, + and${headScripts} + objects have been deleted. Substitute as + shown in the preceding example.
      • propertyGroups.getPropertyAndRemoveFromList() - in the - individual templates has been deprecated. The replacement method is propertyGroups.pullProperty(). - There is no change in functionality. + in + the individual templates has been deprecated. The replacement method ispropertyGroups.pullProperty(). There is no change in + functionality.

      VI. List view changes

      <query-base> and <query-collated> - have been replaced - with a single query <query-select> - that contains - tags for - fragments to be used only in the collated version of the query. This - and other changes are documented in /vitro/doc/list_view_configuration_guidelines.txt.

      VII. Authorization changes

      + have been replaced with a single query <query-select> + that contains tags for fragments to be used only in the collated + version of the query. This and other changes are documented in /vitro/doc/list_view_configuration_guidelines.txt.

      VII. Authorization changes

      - In release 1.3, the VIVO authorization system has some extensive - changes. In summary, these are: + In release 1.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. + Each user will have a user account, even if the user logs in by + Shibboleth or some other external authentication system.
      • - E-mail is used to notify user's when an account is created for - them, or when an administrator edits their account. + E-mail is used to notify user's when an account is created for + them, or when an administrator edits their account.
      • - A "root" user account exists which has access to all pages and - all data fields. This is a powerful tool that can hold some surprises. + A "root" user account exists which has access to all pages and + all data fields. This is a powerful tool that can hold some surprises.

      i. User Accounts are created for externally @@ -879,7 +954,7 @@

      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 so mail was ever sent. In release 1.3, this has + 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 and for communication with the user.

      @@ -890,22 +965,22 @@

      Prior to release 1.3, the Username field (also referred to as - “e-mail address”) was used for several purposes: + '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). + Part of the user’s credentials when logging in (along with a + password).
      • - Connecting the user account to an external authentication - system, like Shibboleth or CUWebAuth. + Connecting the user account to an external authentication + system, like Shibboleth or CUWebAuth.
      • - Connecting the user account to a personal Profile page. + Connecting the user account to a personal Profile page.

      @@ -914,15 +989,16 @@

      • - EmailAddress is used when logging in (along with a password). + EmailAddress is used when logging in (along with a + password).
      • - EmailAddress is used to send notifications to the user about - changes to his/her account (see below). + EmailAddress is used to send notifications to the user about + changes to his/her account (see below).
      • - The ExternalAuthId is used when logging in using an external - authentication system. + The ExternalAuthId is used when logging in using an external + authentication system.
      • The ExternalAuthId is used to connect the user account to a @@ -955,8 +1031,9 @@

        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 plan for this as part of your migration to release 1.3 + the system requires that your e-mail address be in a valid form, like somebody@somewhere.edu. + You + should plan for this as part of your migration to release 1.3

      @@ -1003,9 +1080,9 @@

      The e-mail notification relies on two configuration properties:email.smtpHost - and email.replyTo. If - either of these properties is missing or empty, VIVO will not attempt - to send e-mail notifications to users. + and email.replyTo. If either of these properties is + missing or empty, VIVO will not attempt to send e-mail notifications to + users.

      This can be useful for small or experimental installations of @@ -1019,7 +1096,7 @@

      -

      iii. Each VIVO installation will have a “root” +

      iii. Each VIVO installation will have a 'root' account.

      @@ -1034,7 +1111,8 @@ 

      rootUser.emailAddress = vivo_root@mydomain.edu
      The password for this account is automatically set to rootPassword, - but you will be required to change the password the first time you log + but + you will be required to change the password the first time you log in.
      Note: