Date: Thu, 28 Mar 2024 13:50:09 -0400 (EDT) Message-ID: <1244098365.28508.1711648209578@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_28507_1409631964.1711648209578" ------=_Part_28507_1409631964.1711648209578 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
When VIVO is started for the = first time, its empty triple stores ("triple sources") are initialized with= data from RDF files deployed to the rdf subdirectory of the VIVO home directory. These RDF files are = organized into a number of subdirectories in order to separate different ty= pes of data and to identify which parts of the data will be updated and mai= ntained via edits to the corresponding triple store and which will be modif= ied by subsequent changes to these RDF files.
The top-level subdirectories in the <= /span>rdf directory can be organized into three general categories:
Data about the structure o= f ontologies (the =E2=80=9Cterminological box=E2=80=9D or TBox= )
Example: foaf:Person i= s a class and it is a subclass of foaf:Agent.
Directory:
<= /li>/tbox
Data about specific named = =E2=80=9Cindividuals=E2=80=9D and their relationships (the =E2=80=9Casserti= on box=E2=80=9D or ABox)
Example: Botswana is a= country and it is located on the continent of Africa.
Directory:
<= /li>/abox
Data for configuring the b= ehavior of the Vitro application
Examples:
= li>There is a class group= called =E2=80=9CPeople=E2=80=9D and it has a rank of 1 for sorting in a li= st of class groups.
The SPARQL Update API = is restricted to the root user.
The =E2=80=9CrelatedBy= =E2=80=9D property, when the object is of class vivo:Authorship, should be = rendered on a profile page with the heading =E2=80=9Cselected publications.= =E2=80=9D
A custom form should b= e used when editing a certain configuration item.
display:NavigationElem= ent is a class used in the configuration data.
Directories:
/applicationMetadata
/auth
/display
/displayDisplay
/displayTbox
Why keep these separate? In a t= ypical VIVO, the data about specific individuals (the ABox) is much larger = than the ontology structure data (the TBox) or the data used for applicatio= n configuration. The latter two are accessed repeatedly and benefit f= rom being cached in memory. By keeping these areas of concerns separate it = is easy to load the ontology definitions and the configuration data into me= mory without performing a complicated process of extracting them from the r= est of the data in the triple store.
VIVO uses two triple sources as confi= gured in applicationSetup.n3 in the VIVO home directory. Data from these di= rectories is stored in the content triple source:
/abox/tbox/applicationMetadata
Data from these directories is stored= in the configuration triple source:
/auth/display/displayDisplay/displayTbox
Within the directories that delineate= the above categories of RDF data, there are further divisions that specify= where the respective data should be stored and updated in the future.
RDF files in =E2=80=9Cfirsttime=E2=80= =9D directories are loaded when the triple store is initialized or upgraded= : that is, the very first t= ime VIVO is started with an empty= triple store, or the first time<= /span> a new version of VIVO is started = with an existing triple store if the new version of VIVO contains an upgrad= ed version of the ontology.
=E2=80=9CFirsttime=E2=80=9D data is e= xpected to be modifiable by end users or system administrators through VIVO= =E2=80=99s Web interface -- either using interactive editing forms or by lo= ading or removing RDF data via the Site Admin page. Firsttime files a= re the standard way of distributing the parts of ontologies that do not hav= e semantic meaning (do not affect the inferences made by reasoners). Prior = to version 1.10, these annotations also included the human-readable labels = applied to classes and properties.
When a new VIVO is started, each RDF = file in each firsttime directory is loaded in its entirety into one of the = application=E2=80=99s triple stores. The data are stored in graphs th= at can be written to by VIVO=E2=80=99s GUI editing interface or modified by= the Add/Remove RDF feature.
When a new version of VIVO is started= with a new version of the ontology, the upgrade process compares the previous version of the =E2=80=9Cfirsttime=E2=80=9D files against the c= urrent state of the triple store. For a given subject and predicate, = if the value in the triple store still matches the value from = the previous version of firsttime -- that is, end users have not made a cha= nge to this data element -- then any changes found in the current version o= f firsttime will be propagated to the triple store.
Example: how VIVO applies RDF updates= when changes have been made using the user interface
Version 0.1 rdf/tbox/first= time/vitroAnnotations.n3 contains the triples =E2=80=98foaf:Person vitro:di= splayRankAnnot =E2=80=9C-1=E2=80=9D^^xsd:int and =E2=80=98foaf:Organization= rdfs:label vitro:displayRankAnnot =E2=80=9C-1=E2=80=9D^^xsd:int=E2=80=99.<= /span>
VIVO is installed with a n= ew empty triple store
Triple from step 1 is load= ed into the triple store.
VIVO is restarted any numb= er of times; the initialTBoxAnnotations.n3 file is no longer consulted.
A user edits the display r= ank in the VIVO UI for the foaf:Person class, changing it to =E2=80=9C9=E2= =80=9D.
Version 0.2 is installed, = where the vitroAnnotations.n3 file now contains the triples =E2=80=98foaf:P= erson vitro:displayRankAnnot =E2=80=9C5=E2=80=9D^^xsd:int and =E2=80=98foaf= :Organization vitro:displayRankAnnot =E2=80=9C2=E2=80=9D^^xsd:int=E2=80=99.= The new code installation continues to use the existing triple store with = all of its data intact.
VIVO is restarted with the= new version.
VIVO=E2=80=99s upgrade pro= cess consults the current and previous vitroAnnotations.n3 files and discov= ers that the foaf:Person class has a new display rank.
It checks the triple store= and sees that =E2=80=9C9=E2=80=9D differs from the previous value of =E2= =80=9C-1=E2=80=9D -- that is, someone has edited it.
It keeps the value that so= meone has entered and ignores the new value of =E2=80=9C5=E2=80=9D found in= the file.
The upgrade process discov= ers that foaf:Organization has a new display rank.
It checks the triple store= and sees that the display rank is =E2=80=9C-1=E2=80=9D and matches the val= ue from the previous version of vitroAnnotations.n3 -- that is, no one has = edited it.
It removes the value =E2= =80=9C-1=E2=80=9D from the triple store and adds the new value of =E2=80=9C= 2=E2=80=9D.
=E2=80=9CEverytime=E2=80=9D files are= used for configuration data RDF files that are loaded each time VIVO start= s and whose statements are added to a temporary in-memory RDF model. = It is not possible to identify which statement came from which file. Data i= n everytime files are not intended to be editable by end users using VIVO= =E2=80=99s GUI interface. Any further updates to the data are to be m= ade on the filesystem, followed by a restart of VIVO.
=E2=80=9CFilegraph=E2=80=9D files are= loaded each time VIVO starts, and the contents of each file are loaded int= o a separate graph in the triple store. Thus, it is possible= to query the triple store and discover from which file a given statement w= as loaded -- or, for example, to output all of the statements that came fro= m a given ontology. Triples in the filegraph files are not deletable = by end users using VIVO=E2=80=99s GUI interface. Any further updates to the= data that require removal of the original triples are to be made on the fi= lesystem, followed by a restart of VIVO. Files in the filegraph direc= tory are the standard method of distributing all parts of existing ontologi= es that have semantic meaning (affect the inferences made by reasoners). Fo= r example, the class hierarchy of the VIVO ontology is not intended to be m= odified by end users because it would make their data incompatible with tha= t of other VIVO users.
When a filegraph file is modified and= VIVO is restarted, a background recomputation of all of VIVO=E2=80=99s inf= erred triples will be performed. This is done in order to take into a= ccount the logical consequences of any new ontology axioms that might have = been added via the modification. (Note that if you shut down VIVO whi= le this background process is running, it will not automatically resume but= may be started again manually via the =E2=80=9CRecompute inferences=E2=80= =9D link on the Site Admin page.)
When VIVO is started, the contents of= the file at rdf/tbox/filegraph/v= ivo.owl are compared to the conte= nts of the graph http://vitro.mannlib.cornell.edu/filegraph/tbox/vivo.owl= in the triple store. (= Specifically, it is tested to see if the two graphs are isomorphic or have the same shape.)
If the contents differ, the graph in = the triple store is emptied and the statements from the file are l= oaded into it. After a reload, a complete recomputation of VIVO=E2=80=99s i= nferences is triggered.