Project Management

This section describes how Semantic Turkey manages projects. Please note that all the information here are based on the multi-project management features introduced in version 0.10

Overview

Projects in ST are organized and retrieved through a merely file-based approach. There is no database listing the projects, nor global metadata about projects as each project contains all the information about it and its relations with other projects. However, at run-time a ProjectManager maintains in-memory structures which keep track of open projects, their dependencies, which Consumer(s) opened them, and caches the information stored inside their metadata files.

The Project Structure

Projects are located in the SemanticTurkeyData folder which is created automaticallty the first time ST is being started. In particular, the path to the projects folder is:

<SemanticTurkeyData>/projects

Each subdirectory of the projects directory is a project (thus, never create any directory inside the projects folder if you are accessing it!). The name of the directory coincides with the project name.

The structure of each project is the following:

The store folder may contain the RDF data related to that project. Whether the content is actually stored there, depends on the RDF triple store adopted in that specific project and on the way it is being used. Some projects may adopt a remote connection to a triple store which manages the data in its own folders, while some others may use a triple store API to build a local dataset. In the second case, the store folder is the place where to keep the data: the content of this folder also depends again on the specific triple store being adopted and on the way it is being used.

The project.info file contains generic metadata about the project. Please consider reading the Project Management section of the user manual to get a full understanding of how a project is being managed. Here we we just provide a description of what is stored behing-the-scenes:

From version 0.10 of Semantic Turkey, there are two other important properties which are used in multi-project management:

The model.config file hosts the serialization of the specific model configuration chosen for the OWLART implementation adopted in this project

The PrefixMappings.xml file (which has extension xml for historical reason, but is actually a textual property file) hosts a series of <namespace, prefix> pairs for resolving URIs into their prefixed form.

Project Access Control

From version 0.10 of Semantic Turkey, we decided to definitely move away from the original concept of a desktop application, and embrace the architecture of a fully fledged Project Management Server. In this new scenario, we can have multiple lightweight clients (like the Semantic Turkey Firefox application) accessing the same server and using (each of them) one project at a time, or multi-user collaborative platforms (such as VocBench) taking complete control of Semantic Turkey's Project Management features.

Another objective we fullfilled is to allow inter-project actions, with users accessing one project, being able to visualize the data in other projects (the typical scenario is "ontology alignment"). To do this, we defined Access Control Lists, describing how projects can be accessed from other projects.

In this section, we describe the current system for multiple project management. The following hypotheses drive the way Access Control is managed:

In the new Project Management API (updated in the new ProjectManager, and exposed as services through the Projects service class), there are no more (public) open/close project methods. Requests can instead be made, by consumers, to access projects, and intention to be disconnected from projects can be sent to the ProjectManager as well.

Project Consumers may request access to a project through the service:


public void accessProject(ProjectConsumer consumer, String projectName, ProjectACL.AccessLevel requestedAccessLevel, ProjectACL.LockLevel requestedLockLevel) 
            throws InvalidProjectNameException, ProjectInexistentException, ProjectAccessException, ForbiddenProjectAccessException

The ProjectManager verifies that the access can be granted to the requesting consumer, and in affirmative case handles all the necessary operations (verifying that the project is open, or opening it in negative case and adding it to the list of open projects) to make the project available to the consumer.

Project Consumers may request to be disconnected from a given project through this service:


public void disconnectFromProject(ProjectConsumer consumer, String projectName) throws ModelUpdateException

if the consumer requesting disconnection is SYSTEM, then the project idenfied by projectName is disconnected in turn from all of the projects it consumes.

The Access Control List

Each project contains an Access Control List, representing the consumers that can access its content. Formally, it consists of two elements:

The AccessLevel can have two values: R (read), or RW (read/write). This tells if the project's content can be accessed (R or RW) by the paired consumer, and if the consumer may also edit this content (RW). The sole presence of a ProjectConsumer in a Project's ACL thus enables that consumer to access the project's content.

Locking works in a different way from traditional locks (actually, its values have to be read the opposite way: we were tempted to give it a different name, though we ended up deciding that, whichever way it is managed, it still represent a lock!). Traditional locks are usually activated by a controller (e.g. an Operating System) whenever an agent tries to access a resource (e.g. a file) managed by it. The way in which the resource is being used by the agent, automatically implies that the resource is locked in that way. For instance, a read-write operation on a file, implies the file cannot be accessed, because its content is subject to change. However, projects contain large non-atomic data repositories which can be potentially accessed in parallel by different actors. Atomic operations are in any case guaranteed to not overlap with each other by means of ACID transactions, and this is independent of the consumer (two users could make an attempt to touch the same data even from the same consumer). Thus, the LockLevel is more concerned with establishing a level of global exclusiveness on the access to a project, for a certain consumer.

The LockLevel associated to each project, and reported in its ProjectACL, can assume the following values:

Thus, this form of locking describes not the kind of access which is being currently done on the resource (in fact, there could be more consumers accessing in parallel, with different levels, the same project), but the kind of access which is being forbidden by a single consumer asking for exclusiveness on that same form of access. As a consequence, R is the strongest form of lock, as it prevents other consumers from doing READ operations (and, implicitly, even WRITE ones).

Online Access Status

The Access Control List describes the access allowances established for each project in a given Semantic Turkey system. These reflect the possibilities for various consumers to access each project. The Online Access Status represents instead the actual list of consumers which requested access to the project in the current running system.

Access requests are evaluated by both considering the ACL and the online status of a project. The ProjectManager keeps track of the status of all projects, telling whether they are open, which consumers are accessing them and with which AccessLevel, and if a Lock has been set on them. Whenever an access request to a given project comes from a consumer, the ProjectManager performs a series of checks, by first analysing static compatibility of the consumer with the ACL of the project to which access is requested, and then examining if the online status of the project (alone, or combined with the ACL) forbids the request.

When a project is created:

This way, a project created through SYSTEM, initially can only be directly accessed by users in read/write mode (SYSTEM consumer RW mode), but their data cannot be inspected by other projects in turn. NO lock is active on it, though this option is useless until a new consumer is added to the ACL (as only SYSTEM can access its content)