Versions Compared

Old Version 37

changes.mady.by.user Mike Conlon

Saved on

compared with

New Version Current

changes.mady.by.user Mike Conlon

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

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.

...

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.rdfIn VIVO, homePageDataGetters  searchIndexerConfigurationVitro.n3 , localeSelectionGUIpageList.n3    vitroSearchProhibited.n3
  • In VIVO homePageDataGetters.n3   vivoConceptDataGetters.n3 localeSelectionGUI.n3   vivoListViewConfig.rdf n3ModelChangePreprocessors.n3  vivoOrganizationDataGetters.n3 orcidInterfaceDataGetters.n3  vivoQrCodeDataGetter.n3 searchIndexerConfigurationVivo.n3 , vivoDepartmentQueries.n3, vivoListViewConfig.rdf, 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, additionalHiding.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 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.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
  • owl, vitroPublic.owl
  • In VIVO 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

...

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() 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.

 

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.

...