Concepts

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.

Divisions in the knowledge base

Depending on what you want to do with the data, it can be useful to sub-divide it by one or more of the following criteria:

Types of statements

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 Request lifespan is used extensively, since it provides a convenient way to manage database connections and minimize contention for resources.

Purpose vs. scope

It is tempting to think of the models of the Servlet Context as equivalent to the unfiltered models of the Request. And in fact, they may represent the very same data. However, the unfiltered models in the Request go out of scope when the Request has been satisfied. As such, it is much easier to manage the resources required by these models. By contrast, the models of the Servlet Context never go out of scope until VIVO is shut down. Any resources such as database connections or processor memory are not easily reclaimed from these models.

Initializing the Models

Application data (Display model)

Name: http://vitro.mannlib.cornell.edu/default/vitro-kb-displayMetadata

Source: the application Datasource (MySQL database)

If empty, read the files in /WEB-INF/ontologies/app/ (without subdirectories)

Every time, read /WEB-INF/ontologies/app/loadedAtStartup

User Accounts

Name: http://vitro.mannlib.cornell.edu/default/vitro-kb-userAccounts

Source: the application Datasource (MySQL database)

If empty, read the files in /WEB-INF/ontologies/auth (without subdirectories). None expected, except during Selenium tests.

The ModelAccess class

Transition from previous 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

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.

Notes:

• The default WebappDaoFactory is the one backed by the unionOntModelSelector. On the request level, this is also known as the "fullWebappDaoFactory". The convenience methodsgetWebappDaoFactory() and setWebappDaoFactory(wdf) support this use.

• "baseWebappDaoFactory" and "assertionsWebappDaoFactory"  are both previous terms for the WebappDaoFactory backed by the baseOntModelSelector. The convenience methods getBaseWebappDaoFactory() and setBaseWebappDaoFactory(wdf) support this use.

• Nobody was using the "deductionsWebappDaoFactory", so we got rid of it.

Future directions?