VIVO Documentation
Page History
...
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 Beginning 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. Regardless of how clean the design might eventually become, this will remain an area with complex requirements which cannot be satisfied by simplistic solutions.
...
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. |
...
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. |
...
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 The RDFService
interface, which has increased increases 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. New structures have been added, but none removed.
...
depending on the particular model.
Note |
---|
The initialization has changed in release 1.6. For the details prior to release 1.5, see RDF initialization before release 1.6 |
Where are the RDF files?
In the distribution, the RDF files appear in [vivo]/rdf
and in [vitro]/webapp/rdf
. These directories are merged during the build process in the usual way, with files in VIVO preferred over files in Vitro.
During the VIVO build process, the RDF files are copied to the VIVO home directory, and at runtime VIVO will read them from there.
...
- In Vitro, there are none
- In VIVO,
initialSiteConfig.rdf, classgroups.rdf and propertygroups.rdf
User Accounts
Contains login credentials and assigned roles for VIVO users.
...
- In Vitro, there are none (except during Selenium testing)
- In VIVO, there are none.
Every time, read the files in rdf/auth/everytime
- In Vitro, permissions
permission_config.n3
- In VIVO, there are none.
The Display model
...
If this model is empty, read the files in rdf/display/firsttime
- In Vitro,
application.owl, menu.n3, profilePageType.n3, pageList_editableStatements.n3
- VIVO contains its own copy of menu.n3, which overrides the one in Vitro
aboutPage.n3 menu.n3 PropertyConfig.n3 PropertyConfigSupp.n3
Every time, read the files in rdf/display/everytime
- in Vitro,
dataGetterLabels.n3 permissions.n3 displayModelListViews.rdf
searchIndexerConfigurationVitro.n3 pageList.n3 vitroSearchProhibited.n3
- In VIVO In VIVO,
homePageDataGetters.n3
, localeSelectionGUIvivoConceptDataGetters.n3
, vivoDepartmentQuerieslocaleSelectionGUI.n3
,vivoListViewConfig.rdf
,n3ModelChangePreprocessors.n3 vivoOrganizationDataGetters.n3 orcidInterfaceDataGetters.n3 vivoQrCodeDataGetter.n3 searchIndexerConfigurationVivo.n3 vivoSearchProhibited.n3
Display TBox
The TBox for the display model.
...
Every time, read the files in rdf/displayTbox/everytime.
- In Vitro,
displayTBOX.n3
- In VIVO, there are none
DisplayDisplay
...
Every time, read the files in rdf/displayDisplay/everytime
- In Vitro,
displayDisplay.n3
- In VIVO, there are none.
Initializing Content models
...
If first setup, read the files in rdf/abox/firsttime
- In Vitro, there are none
- In VIVO,
geopolitical.ver1.1-11-18-11.individual-labels.rdf
, vocabularySource-labels.n3
Every time, read the files in rdf/abox/filegraph
, and create named models in the RDFService. Add them as sub-models to the base ABox. If these files are changed or deleted, update the RDFService accordingly.
- In Vitro, there are none
- In Vivo, VIVO
documentStatus.owl academicDegree.rdf
, continents.n3, dateTimeValuePrecision.owl, documentStatus.owl,geopolitical.abox.ver1.1-11-18-11.owl
,us-states.rdf
,continents.n3 validation.n3 dateTimeValuePrecision.owl vocabularySource.n3
- Plus whatever data packages you may have added. See Managing Data Packages
base TBox
Name: http://vitro.mannlib.cornell.edu/default/asserted-tbox
...
- In Vitro, there are none
- In VIVO, geopolitical-ver1.1-11-18-11-annotations.rdf, isDefinedBy-1.5-annotations.rdf, scires-1.5-annotations.rdf, vitro-0.7-annotations.rdf, vivo-core-1.5-annotations.rdf, vivo-core-1.5-labels_es_ES.n3additionalHiding.n3 initialTBoxAnnotations.n3
Every time, read the files in rdf/tbox/filegraph
, and create named models in the RDFService. Add them as sub-models to the base TBox. If these files are changed or deleted, update the RDFService accordingly.
- In Vitro,
vitro-0.7.owl, vitroPublic.owl
- In VIVO , geopolitical.tbox.ver1.1-11-18-11.owl, isDefinedBy-1.5.owl, scires-1.5.owl, vivo-bibo-1.5.owl, vivo-c4o-1.5.owl, vivo-core-1.5.owl, vivo-dcelements-1.5.owl, vivo-dcterms-1.5.owl, vivo-event-1.5.owl, vivo-fabio-1.5.owl, vivo-foaf-1.5.owl, vivo-pws-1.5.owl, vivo-skos-1.5.owl
base Full
Source: a combination of base ABox and base TBox
inference ABox
-
education.owl personTypes.n3 agent.owl event.owl process.owl appControls-temp.n3 geo-political.owl publication.owl bfo-bridge.owl grant.owl relationship.owl bfo.owl linkSuppression.n3 relationshipAxioms.n3 classes-additional.owl location.owl research-resource-iao.owl clinical.owl object-properties.owl research-resource.owl contact-vcard.owl object-properties2.owl research.owl contact.owl object-properties3.owl role.owl data-properties.owl objectDomains.rdf sameAs.n3 dataDomains.rdf objectRanges.rdf service.owl dataset.owl ontologies.owl skos-vivo.owl date-time.owl orcid-interface.n3 teaching.owl dateTimeValuePrecision.owl other.owl vitro-0.7.owl documentStatus.owl outreach.owl vitroPublic.owl
- Plus whatever ontology extensions you may have added
base Full
Source: a combination of base ABox and base TBox
inference ABox
Name: http://vitro.mannlib.cornell.edu/default/vitro-Name: http://vitro.mannlib.cornell.edu/default/vitro-kb-inf
Source: named graph from the RDFService
...
Source: a combination of union ABox and union TBox
Transition from previous methods
Note |
---|
TBD - What are we transitioning from? Check out VIVO-82. |
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 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.
...