myExperiment describes itself as a “Social Virtual Research Environment” that provides the ability to share Research Objects (ROs) over a social infrastructure to facilitate actioning of research. The myExperiment Ontology is a logical representation of the data model used by this environment, allowing its data to to be published in a standard RDF format, whilst providing a generic extensible framework that can be reused by similar projects. ROs are data structures designed to semantically enhance research publications by capturing and preserving the research method so that it can be reproduced in the future. This paper provides some motivation for an RO specification and briefly considers how existing domain-specific ontologies might be integrated. It concludes by discussing the future direction of the myExperiment Ontology and how it will best support these ROs as well as align with scientific discourse ontologies.
This paper describes the design of an OWL DL [
Section 3 describes the purpose of ROs in semantically enhancing research publications. It briefly considers the requirements of an RO to ensure a scientist can reproduce the research it encompasses and how its design should facilitate this. In particular how the design will provide support for integration of domainspecific ontologies / vocabularies.
myExperiment currently only supports a few basic types of RO. This paper therefore concludes by considering how the myExperiment Ontology needs to evolve to provide greater support for all ROs and how it could align with scientific discourse ontologies. 2 2.1
The myExperiment model has three main features that are motivated by the
four capabilities of a Social VRE:
1. Content Management
2. Social Networking
3. Object Annotation
myExperiment’s initial user group was bioinformaticians that wanted to be able
to manage and share workflows [
When a user joins myExperiment, they can make friends and join Groups, (represented by Friendship and Membership records), to build their social network. Beyond this myExperiment allows users to send each other Messages and make Announcements to their groups. With this social network it makes it possible for Contributions to be shared in a highly customizable way through the use of additive Policies.
Object Annotation allows users to annotate Contributions with Annotations, such as Tags, Ratings, Reviews and Comments to enhance search and to support curation. 2.2
The purpose for building an ontology was to produce a consistent specification for publishing myExperiment’s data as RDF and contributing to the web of data. All of myExperiment’s public data can be accessed via the web3 and queried using myExperiment’s SPARQL endpoint4.
The myExperiment website has been built using the Ruby-on-Rails5
framework. Ruby-on-Rails was chosen because it provides a Model-View-Controller
3 http://rdf.myexperiment.org/
4 http://rdf.myexperiment.org/sparql
5 http://rubyonrails.org/
(MVC) architecture for agile development of web projects allowing rapid
innovation [
Having the myExperiment model already represented in the structured form
of a MySQL database provided both benefits and disadvantages when
designing the myExperiment Ontology. The initial construction of the ontology was
straightforward, as much of the database schema could be transcribed directly
into OWL DL. A number of tools exist that can automate this process [
Ruby-on-Rails uses the database to store information to manage the web interface. In some cases this data would be inappropriate to represent, such as users’ encrypted passwords and salts. In other cases this data is irrelevant such as HTTP session data.
Ruby-on-Rails supports polymorphism. This allows a Contributions table to store generic information about items users want to share and then reference tables such as Workflows and Files that store information specific to that type of Contribution. However, this means that it is impossible to determine from the database schema the different types of Contribution so that they can be represented as subclasses of Contributions within the ontology.
Capturing myExperiment’s customizable sharing model was a key aspect to building the myExperiment Ontology. This is because it is one of the features that makes myExperiment unique in the VRE community. Further to this, the way that Contributions are shared greatly effects the data generated within myExperiment, such as who has tagged a Workflow or how many times a File has been downloaded. Therefore it is important that there is a way of capturing this information concisely. However, this task was complicated by having subjective groups such as friends that vary depending on the user as well as over time.
The Simple Network Access Rights Management (SNARM) Ontology6
allows additive policies to be defined by assigning different types of access to
users, groups and subjective groups. It is extensible to allow the definition of
new types of permission and new subjective groups. Figure 1 illustrates the
relationships between the main entities of the SNARM Ontology, as well as giving
examples of the types of AccessType and Accesser defined in the Specific
module of the myExperiment Ontology, (see section 2.3). At present, the subjective
group Friends is not explicitly defined but this could be achieved by writing a
Semantic Web Rule Langauge (SWRL) [
myExperiment subscribes to the Web 2.0 model of being in “perpetual beta”. This means that it evolves over time as users request new features. This inevitably means the database model is not perfect. In the process of manually building the ontology it became clear where abstractions could be made and this 6 http://rdf.myexperiment.org/ontologies/snarm/ has fed back into the design of the database model to make it simpler and more extensible. 2.3
One of myExperiment’s goals is to encourage reuse of Workflows and other Contributions. For the design of the ontology this ethos was adopted so that it both reuses existing specifications and makes itself as reusable as possible through careful consideration of design decisions.
A number of core ontologies / schemata already exist for representing
properties and classes that exist within myExperiment. The reuse of these gives
myExperiment’s RDF data a graceful degradation of understanding; i.e. if a
machine is presented with some myExperiment RDF, it does not have to be aware
of the myExperiment Ontology to have some understanding of the type of
object it is dealing with. A major task in the Semantic Web world is co-reference
resolution [
The myExperiment Ontology reuses both properties and classes from Dublin Core7, Friend of a Friend (FOAF)8, Semantically Inter-linked Online Communities (SIOC)9 and the Open Archives Initiative’s Object Reuse and Exchange (OAI-ORE)10 ontologies / schemata.
Reusing elements from core ontologies / schemata helps to promote reuse of the ontology, as it makes it easier to understand the purpose of the ontology and 7 http://dublincore.org/ 8 http://www.foaf-project.org/ 9 http://sioc-project.org/ 10 http://www.openarchives.org/ore/ it gives confidence that consideration has been given to the classes and properties defined within. However, this in itself is not enough. The ontology needs to be sufficiently generic so that potential users do not disregard it for being too specific or bloated. At the same time it needs to be expressive enough to represent the whole myExperiment model. To achieve this the myExperiment Ontology has been constructed as a set of modules allowing anyone who reuses them to pick and choose the modules they need. Figure 2 diagrams how the modules bolt together to build the complete myExperiment Ontology. Each module sits atop the modules it requires to define any subclass or sub-property relationships.
The Base module with the assistance of the SNARM ontology provides the bulk of the features described in section 2.1. Figure 3 illustrates the relationships between the main entities in this module. The module uses SIOC as a framework with many of the classes/properties being equivalent or derived from SIOC. It then integrates metadata properties from Dublin Core and FOAF.
The remaining modules support the capability to provide an extensible environment with definitions for specific Contributions, Annotations, usage statistics, etc. In particular the Experiment module is designed to represent the process of actioning research. The Specific module sits over the top and amalgamates all these modules using OWL’s import property to generate an ontology for the whole myExperiment model. It also provides classes and objects that are highly specific to the myExperiment instance at http://www.myexperiment.org/.
A more detailed document describing the ontology specification can be found at http://rdf.myexperiment.org/ontologies/. 2.4
The myExperiment Ontology is quite different to other ontologies in the scientific
discourse community, such as SWAN [
By building the myExperiment Ontology in a modular form it means that additional modules could be built to map to one or more scientific discourse ontologies to allow their vocabularies and concepts to be used within the myExperiment model. 3 3.1
At present the accepted way of publishing research is to have a paper accepted by a conference or journal. These papers are just text documents. They may reference tools and data sources that were used and result sets that were produced. However, there is no certainty that these references will be sufficient to reproduce the research the paper describes. Even if they are, there is no guarantee that these references will still resolve to the item the paper described.
Even if it is possible to repeat the research of the paper, this has overlooked
the problem of actually finding this relevant paper in the first place. [
A Semantic Web approach can assist in such a task, by associating interoperable metadata with these papers. Much of this process can quite easily be automated but when it comes to defining the interrelationships of resources (e.g. data sources, tools and result sets), this requires both an extensible specification and a sea-change in attitudes to what constitutes a research publication. 3.2
Building the myExperiment Ontology has helped to clarify the concept of ROs and how myExperiment “facilitates [the] management and sharing” of them. myExperiment currently has three entities that could be considered ROs: Workflows, Packs and Experiments.
When a Workflow is uploaded various supporting files can also be uploaded or automatically generated, such as SVG and PNG visualizations of the Workflow, all these resources are grouped together. New WorkflowVersions can also be uploaded and are then associated with the original Workflow.
Packs are designed to allow users to collaboratively aggregate resources together by hand. They very closely resemble OAI-ORE Aggregations (see section 3.3). A Pack contains items that are either myExperiment Contributions or external resources. Packs allow metadata to be recorded about these items that is only relevant within the context of that Pack.
Experiments are aggregations of Jobs which in themselves are aggregations of an enacted Workflow with its inputs, outputs and the Runner used to enact it.
These three entities currently require an explicit definition in the database structure / ontology. Supporting all conceivable ROs in this way is impractical. Rather ROs should describe their own structure so that this does not need to be defined in any system that stores them. 3.3
Research Objects (ROs) are designed to aggregate together resources, (e.g.
datasets, workflows, etc.), to represent an investigation, experiment or question [
OAI-ORE is a specification defining how resources can be aggregated [15]. It was designed for the Open Repositories community to allow them to exchange objects between repositories in a standard format. OAI-ORE’s first class object is an Aggregation that can then have one or more items associated with it as Aggregated Resources. Aggregations can be serialized into concrete syntax, such as RDF/XML, Atom Feeds or RDFa, as Resource Maps. The specification allows for metadata to be assigned to all these objects. Metadata pertinent to Aggregated Resources only in the context of the Aggregation can also be assigned using Proxies.
OAI-ORE provides a suitable mechanism for making ROs machine-readable, to make them machine-processable a further specification is needed to help define the interrelationships between resources and the provenance, lifecycle, sharing, curation and usage profiles. The e-Laboratory Technical Architecture Group (eLab TAG)11 is currently working on defining such a specification.
The scientific research ontology [16] allows detailed templates of the whole research process to be defined, through planning, execution to results analysis. This is a shared aim but it is intended for the RO’s main specification to be quite lightweight to make the whole process very flexible, so that an RO can have the level of detail suited to the task at hand. The crucial difference of the RO specification is to provide mechanisms for sharing and social curation of these objects to aid scientists in producing reproducible research, so that other researchers can use the RO to help them plan and execute new experiments. myExperiment plays a key part in providing these mechanisms and the ontology’s modular nature will allow it to represent this support for ROs in a RDF form.
At present it is intended for the specification to have two parts; the Research Object Upper Model (ROUM) to define generic concepts and then individual Research Object Domain Schemas (RODS) for mapping domain-specific concepts. A number of eLab TAG projects, including Taverna12, SysMo13, Obesity e-Lab14 and Shared Genomics 15 are currently developing a RODS alongside their projects.
Several domain-specific ontologies such as the OBI Ontology16 and parts of the SWAN Ontology17, such as the Life Science Entities and the Gene Ontology 11 A collaboration between VRE and related projects at the University of Manchester and University of Southampton. 12 www.taverna.org.uk 13 http://www.sysmo-db.org 14 https://www.nibhi.org.uk/obesityelab 15 https://www.nibhi.org.uk/sharedgenomics/ 16 http://obi.svn.sourceforge.net/viewvc/obi/releases/2009-01-28/merged/OBI.owl 17 http://swan.mindinformatics.org/ontology.html modules, are potential candidates for which RODSs could be constructed allowing ROs for these domains to be defined and to increasing the descriptive power of ROs for the projects discussed previously.
SWAN has recently integrated with SIOC [17] to support the social aspect of scientific discourse. As described in section 2.3, myExperiment has used SIOC as a framework for its Base module, through this shared synergy, it should be possible to identify opportunities for alignment of these two ontologies to allow each of them to benefit from the functionality the other provides. 4
myExperiment stores a large amount of structured data and required a way of providing this data in a standard, consistent and atomic way to make integration with similar systems easier. Building the myExperiment Ontology has facilitated delivering this data as RDF and allowing it to be queried using SPARQL. Having an ontology provides a machine-readable specification that mechanisms such as Representational State Transfer (REST) APIs do not have.
The design of the myExperiment Ontology is a continual process but through careful analysis of the underlying data model it has been designed in an generic way to ensure that future modifications should be additions or minor alterations rather than significant structural changes.
Through the reuse of existing classes and properties from core ontologies / schemata and the modularization of the ontology, a concerted effort has been made to promote reuse of the ontology in similar projects. Modularization should also allow any significant modifications to the myExperiment model to be isolated in new modules rather than requiring changes to existing ones.
In particular, as the concept of ROs becomes more evolved a new module can be constructed to support them. This module will need to integrate with the RO specification ontology to provide an interface with the provenance, lifecycle, sharing, curation and usage profiles stored within an RO, allowing the user to manage these within myExperiment.
If ROs are to be successful and provide a mechanism for publishing reproducible research there needs to be a system to allow their management and sharing prior to as well as post publication. This system should also facilitate the collaborative building of ROs, where multiple researchers, potentially situated in different locations, are involved in the same experiment or investigation. Integrating the myExperiment Ontology with the RO specification ontology should make myExperiment well placed to achieve this. Further to this, the ontology’s modular nature should also allow scientific discourse vocabularies and concepts to be aligned.
Section 3 has been informed by the work of members of the The e-Laboratory Technical Architecture Group, a collaboration between VRE and related projects at The University of Manchester and University of Southampton. 15. Johnston, P., Nelson, M., Sanderson, R., Warner, S.: ORE User Guide - Primer.
Open Archives Initiative. (October 2008) 16. de Almeida Biolchini, J.C., Mian, P.G., Natali, A.C.C., Conte, T.U., Travassos, G.H.: Scientific research ontology to support systematic review in software engineering. Adv. Eng. Inform. 21(2) (2007) 133–151 17. Passant, A., Ciccarese, P., Breslin, J.G., Clark, T.: SWAN/SIOC: Alignment Between the SWAN and SIOC Ontologies (Editor’s Draft). Technical report, W3C (August 2009) Editor’s Draft.