VIVO Documentation
...
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" Defines classes, properties, and relationships in your ontology. |
|
|
ABox | "Assertion data" 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. |
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 | Statements that you explicitly add to the model, either through setup, ingest, or editing. | local:tobyink rdfs:type core:FacultyMember . |
Inferences | 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. |
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 type | Purpose | Examples |
---|---|---|
Configuration | Data about the VIVO application itself. | Application parameters User Accounts Display options |
Content | The payload - the data that VIVO is intended to distribute. | People data Publications data Grant data etc. |
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.
Scope | 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 unfiltered models in the Request go out of scope when the Request has been satisfied. The resources required by these models have short lifetimes and are very easily managed. The models of the Servlet Context never go out of scope until VIVO is shut down. It is difficult to reclaim resources such as database connections or processor memory from these models.
Note |
---|
TBD: talk about language filters and policy filters. What do we mean by "unfiltered?" |
This is a summary of the data models:
To enable language filtering and internationalization of the user interface (translation of data labels and contents, localization, etc.), you should update the runtime.properties file:
|
and then edit the list of needed languages:
|
This is a summary of the data models:
The basic content | Base ABox, Base TBox, Inferred ABox, Inferred TBox | Named graphs from the RDF Service (optionally with sub-graphs). |
Views of the content | Base Full, Inferred Full, Union ABox, Union TBox, Union Full | Views of the |
4 basic content graphs in different combinations. | ||
The configuration | Application Metadata, User Accounts, Display Model, Display TBox, DisplayDisplay | Named graphs from the application datasource. |
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 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:
...
Further, the semantics of the "standard" OntModelSelectors
have changed, so they only act as facades before the Models store in ModelAccess
. In this way, if we make this call:
Code Block |
---|
ModelAccess.on(session).setOntModel(ModelID.BASE_ABOX, someWeirdModel) |
this way, if we make this call:
Code Block |
---|
ModelAccess.on(session).setOntModel(ModelID.BASE_ABOX, someWeirdModel) |
Then both of the following calls would return the same model:
Code Block |
---|
ModelAccess.on(session).getOntModel(ModelID.BASE_ABOX);
ModelAccess.on(session).getBaseOntModelSelector().getABoxModel(); |
Again, this is a change in the semantics of OntModelSelectors. It insures a consistent representation of OntModel
s across OntModelSelector
s, but it is certainly possible that existing code relies on an inconsistent model instead.
Interface for API to write, read, and update Vitro's RDF store, with support to allow listening, logging and auditing. Moreover, it is an intefrace for API to perform a SPARQL select query against the knowledge base. The query may have an embedded graph identifier. If the query does not contain a graph identifier the query is executed against the union of all named and unnamed graphs in the store.
At the end, implementation of this interface should enable serialization of the contents of the named graph to the supplied OutputStream, in N-Triples format.
The root access point for the RDF data structures: RDFServices, Datasets, ModelMakers, OntModels, OntModelSelectors and WebappDaoFactories.
Enables getting a long-term data structure by accessing from the context.
Code Block |
---|
ModelAccess.on(ctx).getRDFService(CONFIGURATION); |
Moreover it enables getting a short-term data structure by accessing from the request.
Code Block |
---|
ModelAccess.on(req).getOntModel(ModelNames.DISPLAY); |
The elaborate structure of options enums allows us to specify method signatures like this on RequestModelAccess:
Code Block |
---|
getOntModelSelector(OntModelSelectorOption... options); |
Which can be invoked in any of these waysThen both of the following calls would return the same model:
Code Block |
---|
ModelAccess.on(session).getOntModel(ModelID.BASE_ABOXreq).getOntModelSelector(); ModelAccess.on(req).getOntModelSelector(LANGUAGE_NEUTRAL); ModelAccess.on(sessionreq).getBaseOntModelSelectorgetOntModelSelector(INFERENCES_ONLY); ModelAccess.getABoxModelon(); |
Again, this is a change in the semantics of OntModelSelectors. It insures a consistent representation of OntModel
s across OntModelSelector
s, but it is certainly possible that existing code relies on an inconsistent model instead.
Note |
---|
TBD |
...
req).getOntModelSelector(ASSERTIONS_ONLY, LANGUAGE_NEUTRAL); |
The compiler insures that only appropriate options are specified. However, if conflicting options are supplied, it will only be caught at runtime
...
.
When VIVO starts up, OntModel
objects are created to represent the various data models. The configuration models are created from the datasource connection, usually to a MySQL database. The content models are created using the new RDFService layer. By default this also uses the datasource connection, but it can be configured to use any SPARQL endpoint for its data.
...
Source: a combination of union ABox and union TBox