myExperiment is a collaborative environment where scientists can safely publish their workflows and experiment plans, share them with groups and find those of others. (Please see the myExperiment Wiki for more detailed information). This results in the myExperiment data model having three main underlying features:
These features are the main focus of the myExperiment Ontology. Fig.1 gives a rough outline of how the main entities of myExperiment interact.
Fig.1 The Main Entities of the myExperiment
The myExperiment Ontology borrows terms from a number of well-known ontologies/schemas to foster reuse by simplifying ontology alignment:
myExperiment borrows terms in a number of ways:
It was decided to construct the ontology in a modularized way to further encourage reuse, where others could pick and choose the modules they wanted to use. The myExperiment ontology currently has 10 modules:
Fig.2 is a class hierarchy diagram for all the classes used in the myExperiment ontology, colour-coded by the module they belong to.
Fig.2 Class Hierarchy Diagram for Ontology Modules
For most of the classes described in Fig.2 RDF examples are available. Modules reuse terms from other modules as well as terms borrowed for the ontologies/schemas previously described. Fig.3 diagrams of how modules borrow from each other with each arrow going from the borrowed-from module/ontology/schema to the borrowing module. The "Base" module is built open by all the other modules (except SNARM). The "Specific" module is slightly different as it imports all the other modules below it. This allows a single URI to be referred to when importing the myExperiment ontology set. Documentation explaining how all the ontology's classes and properties from the ontology can be used is available here.
Fig.3 Ontology Modules Architecture
The Base module contains two classes Contribution and its subclass Upload to represent content objects that can be managed. Contribution is a superclass to describe any content that can be contributed by a User. Upload is designed to only represent content that has been that is uploaded not created online. Upload therefore has additional properties for filename, file URL, file type and licensing.
During the course of the myExperiment project one of the key challenges was providing a flexible and user-friendly interface for user to define who can do what with their contributions. This led to the data model becoming slightly convuluted in this area. Therefore the SNARM ontology was defined to try to rationalise how this information is stored in RDF form.
SNARM uses policies which contain one or more Access objects. Access objects can be unrestricted or restricted to an Accesser that could be a single user, a single group or a more abstract concept such as all the friends or the content owner. The second component of an Access object is the AccessType they provide, e.g. view, edit, download, etc. These types are often quite particular and therefore Specific is used to store these along with abstract Accessers (e.g. Friends) and abstract/unrestricted Access objects (e.g. FriendsEdit, PublicView). A more detailed explanation of SNARM can be found here.
Users can request friendships with other users, which can then be accepted. Users can request membership of a group which may be accepted by the group's owner. A group owner may also request for a user to join a group which the user may then choose to join. All information about the friends a user has and groups they are a member of are store within the Friendship and Membership objects. FriendshipInvitation and MembershipInvitation are similar to their non-invitation counterpart except the request is made to an external party via an email address.
Friendships and Memberships are separate objects from the User or Group. However, it is possible to write SWRL rules to infer is-friends-with and (is/has)-member triples that can be stored as properties of the User or Group object.
The Base module also contains a Message class for sending messages between users within myExperiment.
No data for the Annotation is stored as part of the Contribution rather the Contribution is pointed to by the Annotation. Fig.4 is an RDF graph of an example Annotation:
Fig.4 Example Annotation (A Tagging)
The Packs module provides a way for aggregating myExperiment Contributions and external URLs within a single object and implements the OAI-ORE Specification (see example). Packs are a subclass of OAI-ORE schema's Aggregation class. To allow metadata to be associated only with an AggregatedResource when it occurs within a particular Aggregation, the Packs module implements two ORE Proxy classes:
Remote Pack Entries are pointers to URLs (see example) whereas Local Pack Entries have a pointer (mepack:requires) to specify the myExperiment Contribution they represent (see example). Packs contain the property ore:isDescribedBy to allow the discovery of the associated ResourceMaps allowing the Pack to be exported to another repository (see example).
As well as describing items in a Pack it is possible to describe the relationships between them. A RelationshipEntry allows two items to be link together with a predicate. These predicates can be described in user-defined ontologies. A RelationshipEntry is similar to a LocalPackEntry or RemotePackEntry in that it refers to a Relationship and allows its use it with the context of a particular Pack. It does this by using a ore:proxyFor to the Relationship and an ore:ProxyIn to the Pack, (see Fig.5). A RelationshipEntry differs from LocalPackEntry and RemotePackEntry because it can be used to assert a Relationship in the context of any entity, not just a Pack.
Fig.5 Example Structure of a Pack (Research Object)
A Relationship is made up of an RDF, subject, predicate and object. URI is a UUID version 5 URN (i.e. an SHA-1 hash) generated from the concatenation of the subject, predicate and object URIs. (N.B. So that anyone can generate the same URN for the same triple, no namespace parameter is provided to the UUID generating function). This ensures that all identical relationships have the same URI, essentially indexing relationships to make it easier to find packs that share the same relationships.
myExperiment provides cloud services to run Runnable Contributions (e.g. Workflows) in remote Runners. These cloud services are provided by the Experiments module. An Experiment is a specialisation of a Pack that aggregates Jobs, (making Jobs AggregatedResources). Jobs are enacted workflows on a remote runner. A Job contains all the information about the Workflow being run, the Runner being used, the inputs/outputs of the Job and status information. The inputs and outputs of a Job have their own URIs so they can be referenced separately. (See an example of a Job). Like Packs, Experiments have an ore:isDescribedBy property to allow the discovery of the associated ResourceMaps allowing them exported to another repository.
Workflows in essence are a number of interlinked processes that have initial inputs and final outputs. Using Taverna workflows as an exemplar six types of Workflow Components have been defined.
All these Workflow Components are encompassed within a Dataflow. Fig.6 shows how these Workflow Components interlink to form a Dataflow. Currently every publicly available Taverna workflow has an executes-dataflow property to it's Dataflow.
Fig.6 Overview of Organisation of Components into a Workflow
A Workflow may have many Processors, each must be one of the following types:
Due to it being possible to nest one Dataflow within another each Workflow Component has a belongs-to-workflow that makes its possible to execute a simple SPARQL query to find all the components of a paticular workflow.