Overview

Frequently, we talk about "the data model" in VIVO. But this is an over-simplification which can be useful at times, but misleading at other times. In fact, VIVO contains a matrix of data models and sub-models, named graphs, datasets and other constructs.

It might be more accurate to talk about the union of these data models as "the knowlege base". However, the terminology of "the data model" is firmly entrenched.

In VIVO release 1.6, we are attempting to simplify this complex collection of models, and to produce a unified access layer. This is a work in progress. And regardless of how clean the design might eventually become, this will remain an area with complex requirements which cannot be satisfied by simplistic solutions.

Structure of RDF models

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.

Data type Example data

TBox

"Terminological data"

The data that defines classes, properties, and relationships in your ontology.

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 .

ABox

"Assertion data"

The data that enumerates the individual instances of your classes and describes them.

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

Full

The TBox and the ABox together, treated as a single model.

For example, when you use the RDF tools to remove statements, you want them removed regardless of whether they are found in the TBox or the ABox.

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

Statement type Meaning Example data

Assertions The RDF statements that you explicitly add to the model, either through setup, ingest, or editing. local:tobyink rdfs:type core:FacultyMember .

Inferences

The RDF statements that the semantic reasoner adds to the model, by reasoning about the assertions, or about other inferences.

local:tobyink rdfs:type foaf:Person .

local:tobyink rdfs:type foaf:Agent .

local:tobyink rdfs:type owl:Thing .

Union

The combination of Assertions and Inferences.

For most purposes, this is the desired model. You want to know what statements are available, without regard to whether they were asserted or inferred.

The models

The data models in VIVO can be generally divided into two categories:

Content models	The RDF statements that make up the subject matter of the VIVO. Statements about persons, grants, publications, etc.
Context models	The RDF statements that control the VIVO application. Statements about page formatting, property groups, user accounts, etc.

Topics

Request vs. Session vs. Context
Steps for the future (from VIVO-82 JIRA issue)
Unfiltered is not the same as lower level (unfiltered per request is more efficient than unfiltered from context.
Add comments to explain why each is different.
Talk about where the transition is going
- RDFService increasing

The ModelAccess class

Transition from previous access methods

Semantics have changed: saves code, but may alter some uses.
- Always searches the stack
- OMS are facades with no internal state
  - There is no way to set an OMS - set the models instead
  - Keeps consistent

	prior to ModelAccess	using ModelAccess
User Accounts Model	ctx.getAttribute("userAccountsOntModel")	ModelAccess.on(ctx).getUserAccountsModel()
	ctx.setAttribute("userAccountsOntModel", model)	ModelAccess.on(ctx).setUserAccountsModel(model)
DisplayModel	req.getAttribute("displayOntModel")	ModelAccess.on(req).getDisplayModel()
	session.getAttribute("displayOntModel")	ModelAccess.on(session).getDisplayModel()
	ctx.getAttribute("displayOntModel") ModelContext.getDisplayModel(ctx)	ModelAccess.on(ctx).getDisplayModel()
	ctx.setAttribute("displayOntModel", model) ModelContext.setDisplayModel(model, ctx)	ModelAccess.on(ctx).getDisplayModel()
	req.setAttribute("displayOntModel", model)	ModelAccess.on(req).setDisplayModel(model)
"jenaOntModel"	ctx.getAttribute("jenaOntModel")	ModelAccess.on(ctx).getJenaOntModel()
	session.getAttribute("jenaOntModel")	ModelAccess.on(session).getJenaOntModel()
	req.getAttribute("jenaOntModel")	ModelAccess.on(req).getJenaOntModel()
	ctx.setAttribute("jenaOntModel", model)	ModelAccess.on(ctx).setOntModel(ModelID.UNION_FULL, model)
	req.setAttribute("jenaOntModel", model)	ModelAccess.on(req).setOntModel(ModelID.UNION_FULL, model) ModelAccess.on(req).setJenaOntModel(model)
"baseOntModel" "assertionsModel" Base Full Model	ModelContext.getBaseOntModel(ctx) ctx.getAttribute("baseOntModel") session.getAttribute("baseOntModel")	ModelAccess.on(ctx).getOntModel(ModelID.BASE_FULL) ModelAccess.on(ctx).getBaseOntModel()
	ModelContext.setBaseOntModel(model, ctx)
"inferenceModel" Inference Full Model	ctx.getAttribute("inferenceOntModel")	ModelAccess.on(ctx).getInferenceOntModel()

Notes:

"jenaOntModel" is a previous term for the Union Full model. The convenience methods getJenaOntModel() and setJenaOntModel(m)support this use.
"baseOntModel" and "assertionsModel" are both previous terms for the Base Full model. The convenience methods getBaseOntModel() and setBaseOntModel(m)support this use.

prior to ModelAccess

using ModelAccess

ontModelSelector

unionOntModelSelector

ModelContext.setOntModelSelector(model, ctx)

ModelContext.getUnionOntModelSelector(ctx)

ctx.getAttribute("ontModelSelector")

ctx.getAttribute("unionOntModelSelector")

no mutator methods

ModelAccess.on(ctx).getOntModelSelector()

ModelAccess.on(ctx).getUnionOntModelSelector()

baseOntModelSelector

ctx.getAttribute("baseOntModelSelector")

ModelAccess.on(ctx).getBaseOntModelSelector()

inferenceOntModelSelector

ctx.getAttribute("inferenceOntModelSelector")

ModelAccess.on(ctx).getInferenceOntModelSelector()