Difference between revisions of "Protege Server design"

From Protege Wiki

Jump to: navigation, search
(Tricky points)
(Main concepts)
Line 22: Line 22:
 
     void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;
 
     void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;
 
</pre>
 
</pre>
 +
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==
 
==Plugin Model==

Revision as of 12:04, September 13, 2013


Contents

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

Interfaces

Protege Server Modules

Serialization of ontology changes

Client side revision management

Tricky points

Update after a commit

Out of band interfaces

Personal tools