Difference between revisions of "Protege Server design"

From Protege Wiki
Jump to: navigation, search
(Created page with " =Protege Server Design= ==Main concepts== The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008...")
 
(Main concepts)
Line 8: Line 8:
 
* 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 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 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 server will contain those
+
* 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
 +
<pre>
 +
      org.protege.owl.server.api.server.ServerExports
 +
</pre>
 +
It 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:
 +
<pre>
 +
        Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;
 +
</pre>
 +
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 core idea is that the server provides the abstraction of an evolving ontology through calls that provide the changes made to an ontology between any two revisions.  Thus, for any ontology, the first revision of the ontology will be empty - it will not even have a name.  Then in many cases the delta between the first and second contains all the changes needed to take the empty ontology to what the end user views as his initial version of the ontology.
 
The core idea is that the server provides the abstraction of an evolving ontology through calls that provide the changes made to an ontology between any two revisions.  Thus, for any ontology, the first revision of the ontology will be empty - it will not even have a name.  Then in many cases the delta between the first and second contains all the changes needed to take the empty ontology to what the end user views as his initial version of the ontology.
  
 
 
==Plugin Model==
 
==Plugin Model==
  

Revision as of 11:36, September 13, 2013


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

It 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 core idea is that the server provides the abstraction of an evolving ontology through calls that provide the changes made to an ontology between any two revisions. Thus, for any ontology, the first revision of the ontology will be empty - it will not even have a name. Then in many cases the delta between the first and second contains all the changes needed to take the empty ontology to what the end user views as his initial version of the ontology.

Plugin Model

Interfaces

Protege Server Modules

Ontology Serialization