Versions Compared

Old Version 2

changes.mady.by.user Andrew Woods

Saved on

compared with

New Version 3

changes.mady.by.user Dragan Ivanovic

Saved on

Key

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

...

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"

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"
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.
 

Source of statements
An RDF model can also be divided into Assertions and Inferences. The combination of the two is informally called the Union.
Statement typeMeaningExample data
AssertionsStatements that you explicitly add to the model, either through setup, ingest, or editing. local:tobyink rdfs:type core:FacultyMember . 
InferencesStatements 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.
 

"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 typePurposeExamples
ConfigurationData about the VIVO application itself.
Application parameters
User Accounts
Display options
ContentThe payload - the data that VIVO is intended to distribute.
People data
Publications data
Grant data
etc.
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.
 
ScopePurposeExampleDiscarded when...
Application
(Servlet Context)
Created for the life of VIVO.
 


Never discarded.
SessionCreated for a particular logged-in userData that is filtered by what the user is permitted to view.When the user logs out, or the session times out.
RequestCreated for a single HTTP request
Data that is organized by the languages that are preferred by the browser.
When the individual request has been satisfied.
At present, the Session lifespan is almost never used. However, potential use cases do exist for it.
...
 Note
TBD: talk about language filters and policy filters. What do we mean by "unfiltered?"
 

The Data Models
This is a summary of the data models:
The basic contentBase ABox, Base TBox, Inferred ABox, Inferred TBoxNamed graphs from the RDF Service (optionally with sub-graphs).
Views of the contentBase Full, Inferred Full, Union ABox, Union TBox, Union FullViews of the 4 basic content graphs in different combinations.
The configurationApplication Metadata, User Accounts, Display Model, Display TBox, DisplayDisplayNamed graphs from the application datasource.
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.
...
 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:
...
Source: a combination of union ABox and union TBox