Date: Thu, 28 Mar 2024 16:20:50 -0400 (EDT) Message-ID: <1670008069.28854.1711657250126@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_28853_1856148608.1711657250126" ------=_Part_28853_1856148608.1711657250126 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The next major release of Vitro / VIVO contains an upgrade of Jena - fro= m 2.10.1, to Jena 3.x (3.1.1 at time of writing). Whilst development is sti= ll progressing, in order to maximise amount of testing of this core upgrade= , a beta has been released.
The procedure here describes testing an upgrade from an earlier version = of VIVO. If you have questions, please post to vivo-= tech@googlegroups.com
Jena 3 improves Jena's RDF 1.1 compatibility. Specifically, literal valu= es are always stored internally with datatypes. "Untyped" string literals a= re the same as the identical value typed as xsd:string. See the following d= ocument for more information
= https://jena.apache.org/documentation/migrate_jena2_jena3.html
For VIVO, this means that the two triples:
<subj> <pred> "value"
&l= t;subj> <pred> "value"^^xsd:string
will be treated as the same triple and only stored once in your triple s= tore. As a result, when using the procedure described below to upgrad= e your triple store, you may find that the number of triples in your triple= store after the upgrade is lower than the number before the upgrade.
Any code, tools, parsers, utilities, or queries that expect to different= iate between these two triples will produce results different than produced= previously =E2=80=93 RDF 1.1 no longer distinguishes between these two tri= ples. In particular, queries that limit results based on the xsd:stri= ng datatype will likely produce larger result sets, as previously untyped t= riples are now typed as xsd:string internally.
Another way of saying this =E2=80=93 any triple loaded into VIVO or= Vitro that does not have a type will be typed as xsd:string internally.
Exports from VIVO and Vitro will never include the xsd:string datatype. = Literal values that do not have explicit types are always assumed to = be xsd:string.
As a result, we recommend that input process for VIVO do not include xsd= :string datatypes on literals. While they may be correct, and will re= sult in the literal value being typed as xsd:string internally, export proc= esses will not include the xsd:string on output.
In RDF 1.0, a type could not be asserted with a language identifier. &nb= sp;In RDF 1.1, a type can be asserted with a language identifier. Unt= yped input with language identifiers were left as untyped internally in RDF= 1.0. In RDF 1.1, untyped input with language identifiers are assumed= to have type rdf:langString. Exports from VIVO for triples with lang= uage tags will never include the rdf:langString datatype. Literal val= ues with language tags are always assumed to be rdf:langString.
As a result, we recommend that input process for VIVO do not include dat= atypes on triples with language types. While asserting rdf:langString= is correct, and will result in the literal value being typed as rdf:langSt= ring internally, export processes will not include the rdf:langString on ou= tput.
Code, tools, parsers, utilities based on RDF 1.0 should not be used with= Vitro and VIVO 1.10. All code, tools, parsers, and utilities must su= pport RDF 1.1.
On start-up of version 1.10, the triple store is checked to insure that = it has been upgraded. If untyped literals are found in the triple sto= re, an error message will appear in the browser and the application will no= t start. The test applies only to the content store. It is poss= ible that your content store could pass this test, but your configuration t= riple store remains incompatible with Jena 3 and RDF 1.1. In such a c= ase, your application may become unstable. The procedure below will u= pgrade both your configuration triple store and your content triple store. =
It is required that you reload any SDB and TDB = triple stores when upgrading to Jena 3 using the procedure and tools descri= bed below.
Warning
VIVO/Vitro uses two triple stores =E2=80=93 a configura= tion triple store typically stored using TDB in <vivo home dir>/tdbMo= dels, and a content triple store typically stored using SDB in MySQL.  = ;The procedures described below assume that you are running this standard c= onfiguration. If you are not, you will need a custom procedure for up= grading your triple stores.
Use your local procedure for shutting down Tomcat. To= mcat must be shut down for the upgrade process to proceed.
Download 1.10 beta from GitHub. Follow the instructions for i= nstalling VIVO. Stop prior to starting Tomcat.
To export your triples store, use the jena2tools utility provided with V= IVO 1.10, in <vivo home dir>/bin, specifying the export command, as s= hown below.
java -j= ar jena2tools.jar -d <vivo home dir> -e
Arguments:
-d - the location of the Vitro/VIVO home = directory
-e - run in export mode
On execution, the program will read your configuration files, find your = Vitro or VIVO configuration within the vivo/vitro home directory, and get t= he necessary information to connect to your configuration triple store (usu= ally <vivo home dir>/tdbModels), and your content triple store (usual= ly in SDB). If your triple store(s) are not SDB or TDB backed, then it will= simply skip them.
jena2tools will then extract the contents of the available triple stores= , and dump them to <vivo home dir>/dumps in TriG format.
Check <vivo home dir>/dumps to confirm that the triple stores have= been exported. Inpect the dump files to insure they contain the data= from your triple stores.
Drop all tables in your SDB database as named in your runtime.properties= . You may drop your database and recreate it as empty, just as you wo= uld for creating a new VIVO install. jena3tools must find an empty da= tabase (no tables) as named in your runtime.properties and will recreate yo= ur SDB triple store as tables in the named database using the triples produ= ced by jena2tools and stored in <vivo home dir>/dumps/content.trig
Delete all files in <vivo home dir>/tdbModels. Jena3tools wi= ll rebuild your configuration tdbModels based on the content created b= y jena2tools and stored in <vivo home dir>/dumps/configuration.trig= p>
Having exported your Jena 2 triple stores, you can reload them using jen= a3tools, also available with VIVO 1.10, specifying the import command.
java -j= ar jena3tools.jar -d <vivo home dir> -i
Arguments:
-d - the location of the Vitro/VIVO home = directory
-i - run in import mode
On execution, the program will find your Vitro or VIVO configuration wit= hin the home directory, as well as the dumps that you have created with jen= a2tools. It will import them into the SDB and TDB triple stores, based on t= he configuration of your Vitro/VIVO instance.
jena3tools will be present in <vivo home dir>/bin when you install= the 1.10 beta. Alternatively, it can be downloaded from GitHub.
Using your normal procedure, start Tomcat. Perform your usual star= t-up tests =E2=80=93 login, view pages, conduct searches, examine visu= alizations, perform queries. Please report your findings to vivo-tech@googlegroups.com
When starting Tomcat, does Vitro / VIVO start as expected?
After upgrading, does the application behave as expected? Can you see ev= erything in VIVO, log in, edit content, use the system admin pages, see vis= ualizations, conduct searches, etc.
If you are testing the Vitro / VIVO beta release, please report your fin= dings:
Please report your findings on the vivo-tech@googlegro= ups.com mailing list.
https://github.com/vivo-project/VIVO/releases