Page History

...

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. New structures have been added, but none removed.

Beyond the models

...

There is an incredible variety of ways to access all of these models. Some of this variety is because the models are accessed in different ways for different purposes. Additional variety stems from the evolution of VIVO in which new mechanisms were introduced without taking the time and effort to phase out older mechanisms.

Here are some of the ways for accessing data models:

Attributes on Context, Session, or Request

Previously, it was common to assign a model to the ServletContext, to the HTTP Session, or to the HttpSessionRequest like this:

OntModel ontModel = (OntModel) getServletContext().getAttribute("jenaOntModel");

Object sessionOntModel = request.getSession().getAttribute("jenaOntModel");

ctx.setAttribute("jenaOntModel", masterUnion);

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:

public OntModel getDisplayModel(){     
    if( _req.getAttribute("displayOntModel") != null ){
        return (OntModel) _req.getAttribute(DISPLAY_ONT_MODEL);
    } else {
        HttpSession session = _req.getSession(false);
        if( session != null ){
            if( session.getAttribute(DISPLAY_ONT_MODEL) != null ){            
                return (OntModel) session.getAttribute(DISPLAY_ONT_MODEL);
            }else{
                if( session.getServletContext().getAttribute(DISPLAY_ONT_MODEL) != null){
                    return (OntModel)session.getServletContext().getAttribute(DISPLAY_ONT_MODEL); 
                }
            }
        }            
    }
    log.error("No display model could be found.");
    return null;                
}

This mechanism has been removed in 1.6, being subsumed into the ModelAccess class (see below). Now, the ModelAccess attributes on Request, Session and Context are managed using code that is private to ModelAccess itself. Similarly, the code which gives priority to a Request model over a Session model is uniformly implemented across the models.

It remains to be seen whether this uniformity can satisfy the various needs of the application. If not, at least the changes can all be made within a single point of access.

The DAO layer

This mechanism is pervasive through the code, and remains quite useful. In it, a WebappDaoFactory is created, with access to particular data models. This factory then can be used to create DAO objects which satisfy interfaces like IndividualDao, OntologyDAO, or UserAccountsDAO. Each of these object implements a collection of convenience methods which are used to manipulate the backing data models.

Because the factory and each of the DAOs is an interface, alternative implementations can be written which provide

• Optimization for Jena RDB models
• Optimization for Jena SDB models
• Filtering of restricted data
• and more...

Initially, the WebappDaoFactory may have been used only with the full Union model. But what if you want to use these DAOs only against asserted triples? Or only against the ABox? This led to the OntModelSelector.

OntModelSelectors

The RDF Service

The DAO Layer

OntModel Selectors

Model makers and Model sources

...