VIVO Documentation
Page History
Table of Contents |
---|
The structure of the data models has grown as VIVO has developed. New models, new structures, and new means of accessing the data have been added as required by the growing code. The resulting data layer has grown more complex and more error-prone.
In release 1.5, VIVO added the RDFService
interface, which has increased the flexibility of data sources, and promises to allow a more unified view of the knowledge base. However, the transition to RDFService
is not complete, and so this adds another layer of complexity to the data issues. New structures have been added, but none removed.
Beyond the models
There is an incredible variety of ways to access all of these models. Some of this variety is because the models are accessed in different ways for different purposes. Additional variety stems from the evolution of VIVO in which new mechanisms were introduced without taking the time and effort to phase out older mechanisms.
Here are some of the ways for accessing data models:
Attributes on Context, Session, or Request
Previously, it was common to assign a model to the ServletContext, to the HTTP Session, or to the HttpSessionRequest like this:
Code Block |
---|
OntModel ontModel = (OntModel) getServletContext().getAttribute("jenaOntModel");
Object sessionOntModel = request.getSession().getAttribute("jenaOntModel");
ctx.setAttribute("jenaOntModel", masterUnion); |
Occasionally, conditional code was inserted, to retrieve a model from the Request if available, and to fall back to the Session or the Context as necessary. Such code was sporadic, and inconsistent. This sort of model juggling also involved inversions of logic, with some code acting so a model in the Request would override one in the Session, while other code would prioritize the Session model over the one in the Request. For example:
Accessing the models
There is an incredible variety of ways to access all of these models. Some of this variety is because the models are accessed in different ways for different purposes. Additional variety stems from the evolution of VIVO in which new mechanisms were introduced without taking the time and effort to phase out older mechanisms.
Here are some of the ways for accessing data models:
Attributes on Context, Session, or Request
Previously, it was common to assign a model to the ServletContext, to the HTTP Session, or to the HttpSessionRequest like this:
Code Block |
---|
OntModel ontModel = (OntModel) getServletContext().getAttribute("jenaOntModel");
Object sessionOntModel = request.getSession().getAttribute("jenaOntModel");
ctx.setAttribute("jenaOntModel", masterUnion); |
Occasionally, conditional code was inserted, to retrieve a model from the Request if available, and to fall back to the Session or the Context as necessary. Such code was sporadic, and inconsistent. This sort of model juggling also involved inversions of logic, with some code acting so a model in the Request would override one in the Session, while other code would prioritize the Session model over the one in the Request. For example:
Code Block |
---|
public OntModel getDisplayModel(){
if( _req.getAttribute("displayOntModel") != null ){
return (OntModel) _req.getAttribute(DISPLAY_ONT_MODEL);
} else {
HttpSession session = _req.getSession(false);
if( session |
Code Block |
public OntModel getDisplayModel(){
if( _req.getAttribute("displayOntModel") != null ){
return (OntModel) _req.getAttribute(DISPLAY_ONT_MODEL);
} else {
HttpSession session = _req.getSession(false);
if( session != null ){
if( session.getAttribute(DISPLAY_ONT_MODEL) != null ){
return (OntModel) session.getAttribute(DISPLAY_ONT_MODEL);
}else{
if( session.getServletContext().getAttribute(DISPLAY_ONT_MODEL) != null){
return (OntModel)session.getServletContext().getAttribute(DISPLAY_ONT_MODEL);
}
}
}
}
log.error("No display model could be found.");
return null;
} |
...
It remains to be seen whether this uniformity can satisfy the various needs of the application. If not, at least the changes can all be made within a single point of access.
The DAO layer
This mechanism is pervasive through the code, and remains quite useful. In it, a WebappDaoFactory
is created, with access to particular data models. This factory then can be used to create DAO objects which satisfy interfaces like IndividualDao
, OntologyDAO
, or UserAccountsDAO
. Each of these object implements a collection of convenience methods which are used to manipulate the backing data models.
...
Initially, the WebappDaoFactory
may have been used only with the full Union model. But what if you want to use these DAOs only against asserted triples? Or only against the ABox? This led to the OntModelSelector
.
OntModelSelectors
An OntModelSelector
provides a way to collect a group of Models and construct a WebappDaoFactory
. With slots for ABox, TBox, and Full model, an OntModelSelector
could provide a consistent view on assertions, or on inferences, or on the union. The OntModelSelector
also holds references to a display model, an application metadata model, and a user accounts model, but these are more for convenience than flexibility.
...
Again, this is a change in the semantics of OntModelSelectors. It insures a consistent representation of OntModel
s across OntModelSelector
s, but it is certainly possible that existing code relies on an inconsistent model instead.
The RDF Service
...
Model makers and Model sources
The ModelAccess class
Note |
---|
TBD - Show how it represents all of these distinctions. Describe the scope searching and masking, wrt set and get. Include the OntModelSelectors and WADFs. |
...
- the first time that VIVO starts up,
- if a model is found to be empty,
- every time that VIVO starts up.
depending on the particular model.
...
- .
...
depending on the particular model.
...
Where are the RDF files?
In the distribution, the RDF files appear in [vivo]/rdf
and in [vitro]/webapp/rdf
. These directories are merged during the build process in the usual way, with files in VIVO preferred over files in Vitro.
During the build process, the RDF files are copied to the VIVO home directory, and at runtime VIVO will read them from there.
The "first time"
For purposes of initialization, "first time" RDF files are loaded if the relevant data model contains no statements. Content models may also load "first time" files if the RDFService detects that its SDB-based datastore has not been initialized.
...
- In Vitro, there are none
- In VIVO, geopolitical.ver1.1-11-18-11.individual-labels.rdf, vocabularySource-labels.n3
Every timerestart, read the files in rdf/abox/filegraph, and create named models in the RDFService. Add them as sub-models to the base ABox. If these files are changed or deleted, update the RDFService accordingly.
- In Vitro, there are none
- In Vivo, academicDegree.rdf, continents.n3, dateTimeValuePrecision.owl, documentStatus.owl, geopolitical.abox.ver1.1-11-18-11.owl, us-states.rdf, academicDegree.rdf, continents.n3
us-states.rdf, dateTimeValuePrecision.owl, validation.n3, documentStatus.owl, vocabularySource.n3
base TBox
Name: http://vitro.mannlib.cornell.edu/default/asserted-tbox
Source: named graph from the RDFService (memory-mapped)
If first setup, read the files in rdf/tbox/firsttime (without subdirectories)
- In Vitro, there are none
- In VIVO, geopolitical-ver1.1-11-18-11-annotations.rdf, isDefinedBy-1.5-annotations.rdf, scires-1.5-annotations.rdf, vitro-0.7-annotations.rdf, vivo-core-1.5-annotations.rdf, vivo-core-1.5-labels_es_ES.n3
Every time, read the files in rdf/tbox/filegraph, and create named models in the RDFService. Add them as sub-models to the base TBox. If these files are changed or deleted, update the RDFService accordingly.
...
.mannlib.cornell.edu/default/asserted-tbox
Source: named graph from the RDFService (memory-mapped)
If first setup, read the files in rdf/tbox/firsttime (without subdirectories)
- In Vitro, there are none
- In VIVO, additionalHiding.n3 initialTBoxAnnotations.n3
Every restart, read the files in rdf/tbox/filegraph, and create named models in the RDFService. Add them as sub-models to the base TBox. If these files are changed or deleted, update the RDFService accordingly.
- In Vitro, vitro-0.7.owl, vitroPublic.owl
- In VIVO, 44 files:
Code Block | ||
---|---|---|
| ||
README.md education.owl personTypes.n3
agent.owl event.owl process.owl
appControls-temp.n3 geo-political.owl publication.owl
bfo-bridge.owl grant.owl relationship.owl
bfo.owl linkSuppression.n3 relationshipAxioms.n3
classes-additional.owl location.owl research-resource-iao.owl
clinical.owl object-properties.owl research-resource.owl
contact-vcard.owl object-properties2.owl research.owl
contact.owl object-properties3.owl role.owl
data-properties.owl objectDomains.rdf sameAs.n3
dataDomains.rdf objectRanges.rdf service.owl
dataset.owl ontologies.owl skos-vivo.owl
date-time.owl orcid-interface.n3 teaching.owl
dateTimeValuePrecision.owl other.owl vitro-0.7.owl
documentStatus.owl outreach.owl vitroPublic |
...
.owl |
base Full
Source: a combination of base ABox and base TBox
...