...

An RDF model is often divided into ABox (assertions) and TBox (terminology). In RDF, there is no technical distinction between TBox and ABox data. They are stored separately because they are used for different purposes. The combination of the two is informally called the Full model.

foaf:Person
   a owl:Class ;
   rdfs:subClassOf owl:Thing ;
   rdfs:label "Person"@en . 
ex:preferredName
   a owl:DatatypeProperty ;
   rdfs:subPropertyOf skos:prefLabel,
                      foaf:name, 
                      rdfs:label ; 
   rdfs:domain foaf:Person ;
   rdfs:label "preferred name"@en .

local:tobyink 
   a foaf:Person ;
   ex:preferredName "Toby Inkster" .

Source of statements

An RDF model can also be divided into Assertions and Inferences. The combination of the two is informally called the Union.

local:tobyink rdfs:type foaf:Person .

local:tobyink rdfs:type foaf:Agent . 
local:tobyink rdfs:type

owl:Thing .

"Content" vs. "Configuration"

We sometimes distinguish between the data that VIVO is serving (Content) and the data that VIVO itself uses (Configuration). The Content is available for display, for searching, for serving as Linked Open Data. The Configuration controls how the content is displayed, who can access the data, and what VIVO itself looks like.

Model scope

The knowledge base exists for as long as VIVO is running. However, subsets or facets of the knowledge base are often used to satisfy a particular HTTP request, or through the length of a VIVO session for a particular user. These subsets are created dynamically from the full knowledge base, used for as long as they are useful, and then discarded.

At present, the Session lifespan is almost never used. However, potential use cases do exist for it.

...

The unfiltered models in the Request go out of scope when the Request has been satisfied. The resources required by these models have short lifetimes and are very easily managed. The models of the Servlet Context never go out of scope until VIVO is shut down. It is difficult to reclaim resources such as database connections or processor memory from these models.

Filtering

The Data Models

This is a summary of the data models:

To enable language filtering and internationalization of the user interface (translation of data labels and contents, localization, etc.), you should update the runtime.properties file:

and then edit the list of needed languages:

The Data Models

This is a summary of the data models:

Increasing complexity

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.

...

OntModel ontModel = (OntModel) getServletContext().getAttribute("jenaOntModel");

Object sessionOntModel = request.getSession().getAttribute("jenaOntModel");

ctx.setAttribute("jenaOntModel", masterUnion);

Occasionally, conditional code 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:

...

Further, the semantics of the "standard" OntModelSelectors have changed, so they only act as facades before the Models store in ModelAccess. In this way, if we make this call:

ModelAccess.on(session).setOntModel(ModelID.BASE_ABOX, someWeirdModel)

this way, if we make this call:

ModelAccess.on(session).setOntModel(ModelID.BASE_ABOX, someWeirdModel)

Then both of the following calls would return the same model:

ModelAccess.on(session).getOntModel(ModelID.BASE_ABOX);
ModelAccess.on(session).getBaseOntModelSelector().getABoxModel();

Again, this is a change in the semantics of OntModelSelectors. It insures a consistent representation of OntModels across OntModelSelectors, but it is certainly possible that existing code relies on an inconsistent model instead.

The RDF Service

Interface for API to write, read, and update Vitro's RDF store, with support to allow listening, logging and auditing. Moreover, it is an intefrace for API to perform a SPARQL select query against the knowledge base. The query may have an embedded graph identifier. If the query does not contain a graph identifier the query is executed against the union of all named and unnamed graphs in the store.

At the end, implementation of this interface should enable serialization of the contents of the named graph to the supplied OutputStream, in N-Triples format. 

Model makers and Model sources

The ModelAccess class

The root access point for the RDF data structures: RDFServices, Datasets, ModelMakers, OntModels, OntModelSelectors and WebappDaoFactories.
Enables getting a long-term data structure by accessing from the context.

ModelAccess.on(ctx).getRDFService(CONFIGURATION); 

Moreover it enables getting a short-term data structure by accessing from the request.

ModelAccess.on(req).getOntModel(ModelNames.DISPLAY);

The elaborate structure of options enums allows us to specify method signatures like this on RequestModelAccess:

getOntModelSelector(OntModelSelectorOption... options);

Which can be invoked in any of these waysThen both of the following calls would return the same model:

ModelAccess.on(session).getOntModel(ModelID.BASE_ABOXreq).getOntModelSelector();
ModelAccess.on(req).getOntModelSelector(LANGUAGE_NEUTRAL);
ModelAccess.on(sessionreq).getBaseOntModelSelectorgetOntModelSelector(INFERENCES_ONLY);
ModelAccess.getABoxModelon();

Again, this is a change in the semantics of OntModelSelectors. It insures a consistent representation of OntModels across OntModelSelectors, 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

...

req).getOntModelSelector(ASSERTIONS_ONLY, LANGUAGE_NEUTRAL);

The compiler insures that only appropriate options are specified. However, if conflicting options are supplied, it will only be caught at runtime

...

.

Initializing the Models

When VIVO starts up, OntModel objects are created to represent the various data models. The configuration models are created from the datasource connection, usually to a MySQL database. The content models are created using the new RDFService layer. By default this also uses the datasource connection, but it can be configured to use any SPARQL endpoint for its data.

...

Source: a combination of union ABox and union TBox