Protege Server design

Protege Server Design

Main concepts

The Protege OWL Server is loosely based on the ideas expressed in a paper that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps

• The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.
• The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.
• The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.

The server interface as seen by a client is contained in the class org.protege.owl.server.api.server.ServerExports. This class is intentionally a very lean interface; it currently contains only seven interface methods. The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:

        Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;

This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions

           ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;

and some interfaces to commit changes to the server:

    void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;

In addition to these simple interfaces supporting the main functionality of the server, that is maintaining the change sets between different versions of ontologies, the server has support for orthogonal requirements such as authentication and the enforcement of policies for reading and/or writing ontologies.

Plugin Model

While a server may be configured in a programatic fashion, one of the primary methods of running the server uses a plugin architecture. In this plugin architecture, jar files for server plugins are placed in a directory where they are automatically loaded and then configured to work together by following the instructions in a server configuration file. This plugin mechanism is based on the OSGi declarative services. There are four main types of extensions that a plugin may make to the Protege OWL Server:

• A core server. The server is the core component that implements all the server interface which includes both public interfaces that are accessible to the client as well as server private interfaces that are only accessible by plugins on the server.
• A server filter extension. This type of extension intercepts all calls to the server and may perform arbitrary processing either before or after calling the server. Examples of server filters include
  • extensions that check that a given call is consistent with policy,
  • extensions that check that the caller is properly