Protege Client Server Tutorial Configuration
Protege Server Configuration
This page describes the configuration of the Protege server including: the metaproject, creating users and policies. This page is part of the Protege client-server tutorial.
This section describes how to configure the projects that are available from the Protege server. (Read this section only if you have succeeded in performing the steps from the section Protege Server Setup.
The metaproject, located by default in the
examples\server subdirectory of the Protege installation directory, contains information about which Protege projects are exported, i.e. available to Protege clients, and which users have access to these projects. It also stores policy configurations. Note that the built-in security concerning which users can access which projects is on top of whatever other security your system provides, e.g. a firewall.
Use Protege to open the metaproject and spend some time browsing the class hierarchy. You will find a very simple ontology of users, security, and projects:
Instances of the Project class will be made available to people identified with instances of the User class. The security model represented by the metaproject ontology is essentially equivalent to the security model of the Unix file system. Permissions are divided into read and write access for users categorized into owner, group, and World. Every project has exactly one owner and users may be a member of any number of groups. World is a group that has everyone as a member (this is ensured by making World to be the default value of template slot group for class User). The Unix security model is extended a bit in the sense that individual users can be given specific access to a project.
If you examine instances of the User class, you will find the default Guest user. For the security conscious, your first task should be to delete the Guest user, and any other default users. (Before doing this, you may want to try creating some new users and ensure that they can successfully connect).
If you examine instances of the Project class, you will encounter among others the Newspaper and Collaborative Pizza projects. Note that these are just references to projects that exist on your disk as part of the default Protege installation. Also note that the specified file locations are relative to the Protege installation directory (actually the current working directory) rather than to the location of the metaproject. If you find this confusing, you can always specify the file locations as absolute paths. On a Window machine, for example, you can specify the absolute path as
C:/MyProject/kbs/MyProtegeKB.pprj. If you have other projects that you have created and you want to make them available in the client-server version, you should create instances of these projects in the metaproject. (We recommend making a copy of the metaproject first, just in case!). Remember to configure the security for your projects since by default, only the owner has access to a particular project.
After editing the metaproject, save it and restart the Protege server (changes only take effect after the Protege server restart). There is currently no way for the server to read an updated metaproject (we may provide this in the future). You should now be able to see the results of your changes, such as additional projects and users, when you connect from a new client.
Main Metaproject concepts
The main classes of the metaproject ontology are explained briefly below:
- User - instances of this class will be the actual users who can login into the Protege server. A user has a user name, a password, a description, and can belong to one or more groups (or none). To create a new user, select the class User and create a new instance and fill in the slots (property) values.
- Group - instances of this class are the groups available in the Protege server. A group has a name, a description and members of type User. If you add a user to a group, the inverse relationship is create automatically (e.g., John is in the Editors group, then the Editors group will have as a member John).
- Operation - instances of this class represent the operations available in the Protege editor (or in your own application that accesses the Protege server). An operation has a name and a description. The metaproject comes with some predefined operations: Read, Write, DisplayInProjectList.
- Read - is the operation of reading an ontology on the server. This operation is enforced in the Protege clients and in the API. If a client does not have the read right on a project, she will not see in the client the project in the available project list after logging in the Protege server.
- DisplayInProjectList - if a project does not have this operation associated to it, then the project will not be displayed in the available project list when a user logs into the server. This operation is useful, if you want to hide certain projects from the available projects list for the users, but you still want to be able to read them. A good example is the changes and annotations project that is used by collaborative Protege. You would not want the users to see the annotations project and open it directly in the client.
- Write - the write operation on an ontology. In the current version, this operation is not enforced in the Protege UI or API. We may provide this functionality in future versions.
- GroupOperation - instances of this class associate one or more groups of users with a set of operations. A predefined GroupOperation instance in the metaproject is the
World can Read and Write. The group operations are not useful as stand alone instances, but they are associated to projects. For example, to the Collaborative Pizza project, we associate the group operation
World can Read and Write, meaning that all the users who open the Collaborative Pizza project from a Protege client, will be able to read and write this project.
- Project - the most important class. This is where you will start by creating project instances and for navigation. The Project instances represent actual projects stored on the server side. These projects will be available to Protege clients that connect to this server. A project has:
- a name - it may contain spaces, this is what is displayed in the available projects list on the client
- a description - some text or documentation about the project
- a location - can be relative to the Protege server installation directory, or absolute
- policies - are associated to the project as instance of GroupOperation
- an annotation project - is optional. If you want to use Collaborative Protege or the Change Tab on the server, you need to configure this project. Step-by-step instructions are available here. For example, the Collaborative Pizza has an associated annotation project called Collaborative Pizza Annotations (also a "normal" project; an instance of Project class)
Create new users from the client
By default, the server will disallow the creation of new users in the "Login to Server" panel when clicking on the "New user" button. To allow the creation of new users by clicking on the "New user" button on the client, add to the
protege.properties file the following line:
After editing the protege.properties, you need to restart the Protege server, for the changes to take effect.
Read more about the Protege multi-user support in the Protege client-server tutorial.