VIVO Documentation
Page History
...
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
...
scope
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 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.
LifespanScope | 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. |
...
The Request lifespan is used extensively, since it provides a convenient way to manage database connections and minimize contention for resources.
Topics
...
Purpose vs.
...
scope
Note |
---|
TBD - unfiltered is not the same as |
...
larger scope. unfiltered per request is more efficient than unfiltered from context. |
...
Initializing the Models
Note |
---|
TBD - Mention the criteria, the file paths. Include the filegraph and other directories and files. |
The ModelAccess class
Note |
---|
Show how it represents all of these distinctions. Describe the scope searching and masking, wrt set and get. |
...
- RDFService increasing
...
Transition from previous
...
methods
Note |
---|
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 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.
...
Future directions?
Note |
---|
What are we transitioning toward? From VIVO-82 |