VIVO Documentation
Old Release
This documentation relates to an old version of VIVO, version 1.9.x. Looking for another version? See all documentation.
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.
Data type | Example data | |
---|---|---|
TBox | "Terminological data" The data that defines classes, properties, and relationships in your ontology. |
|
ABox | "Assertion data" The data that enumerates the individual instances of your classes and describes them. |
|
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 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. |
|
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. "Context"
We sometimes distinguish between the data that VIVO is serving (Content) and the data that VIVO itself uses (Context). The Content is available for display, for searching, for serving as Linked Open Data. The Context controls how the content is displayed, who can access the data, and what VIVO itself looks like.
Model type | Purpose | Examples |
---|---|---|
Context | Data about the VIVO application itself. | Configuration data User Accounts Display options |
Content | The payload - the data that VIVO is intended to distribute. | People data Publications data Grant data etc. |
Model lifespan
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 login 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.
Lifespan | Purpose | Example | Discarded when... |
---|---|---|---|
Application (Servlet Context) | Created for the life of VIVO.
| Never discarded. | |
Session | Created for a particular logged-in user | Data that is filtered by what the user is permitted to view. | When the user logs out, or the session times out. |
Request | Created 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.
The Request lifespan is used extensively, since it provides a convenient way to manage database connections and minimize contention for resources.
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()
andsetJenaOntModel(m)
support this use.- "baseOntModel" and "assertionsModel" are both previous terms for the Base Full model. The convenience methods
getBaseOntModel()
andsetBaseOntModel(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() |
Notes:
- The default WebappDaoFactory is the one backed by the unionOntModelSelector. On the request level, this is also known as the "fullWebappDaoFactory". The convenience methods
getWebappDaoFactory()
andsetWebappDaoFactory(wdf)
support this use. - "baseWebappDaoFactory" and "assertionsWebappDaoFactory" are both previous terms for the WebappDaoFactory backed by the baseOntModelSelector. The convenience methods
getBaseWebappDaoFactory()
andsetBaseWebappDaoFactory(wdf)
support this use. - Nobody was using the "deductionsWebappDaoFactory", so we got rid of it.