Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 typeExample 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 typeMeaningExample data
AssertionsThe RDF statements that you explicitly add to the model, either through setup, ingest, or editing.local:tobyink rdfs:type core:FacultyMember .
InferencesThe 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 modelsThe RDF statements that make up the subject matter of the VIVO. Statements about persons, grants, publications, etc.
Context modelsThe 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

...