VIVO Documentation
Page History
Table of Contents |
---|
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.
...
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 Regardless of how clean the design might eventually become, this will remain an area with complex requirements which cannot be satisfied by simplistic solutions.
...
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 They may even represent the very same data. However, they have different scope, which makes them very different in practice.
The , 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 The resources required by these models . By contrast, the have short lifetimes and are very easily managed. The models of the Servlet Context never go out of scope until VIVO is shut down. Any It is difficult to reclaim resources such as database connections or processor memory are not easily reclaimed from these models.
The ModelAccess class
from these models.
The Data Models
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. |
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.
In release 1.5, VIVO added the RDFService
interface, which has increased the flexibility of data sources, and promises to allow a more unified view of the knowledge base. However, the transition to RDFService
is not complete, and so this adds another layer of complexity to the data issues.
Beyond the models
The RDF Service
The DAO Layer
OntModel Selectors
Model makers and Model sources
The ModelAccess class
Note |
---|
Show how it represents all of these distinctions. Describe the scope searching and masking, wrt set and get. |
...
Initializing the Models
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.
...