Research Objects (ROs) provide a exible model to collate and describe the semantic context of science. In this position paper we describe how ROs can also provide a foundation for interoperability within RESTful architecture design, enabling the development of new services and clients alongside compatible enhancements to existing software including myExperiment. To illustrate this we introduce an infrastructure, known as the Wf4Ever Toolkit, providing services and clients to encapsulate, preserve, and re-use ROs.
While a workow can describe an experiment, to aggregate the wider digital
context of scientic processes and their conduct input and output data, method,
software, actors, analysis, dissemination, sharing, re-use, and the links and
relationships between these gathered resources we need Research Objects (ROs)
[
Services implement shared provision of functionality accessed through one or more APIs (each may be implemented by one or more service). The next section outlines a number of implemented services that demonstrate the interoperability aorded by adoption of an RO-centric architecture. 3
The business of capturing, enhancing, and preserving the scientic process is undertaken by the Wf4Ever Toolkit 10, an RO-centric architecture with services categorised within three layers and four functional sub-groupings (gure 1; in the following text services and APIs in bold, conceptual models sans serif ).
Storage services . The Toolkit makes use of two storage services constructed around the core RO model. The RO Digital Library (RODL) provides foundational capabilities within the Toolkit and a reference implementation of the RO Storage and Retrieval (ROSR) API . Extending the dLibra Digital Library software, RODL provides core functionality including (i) Retrieval: serving ROs to clients in multiple representations via content-negotiation including selfcontained zip archives and RDF manifest descriptions, provision of indexing and query interfaces (including SPARQL) for ROs and their metadata; (ii) Storage: creating, editing and deleting internal and external resources and annotations 9 http://www.wf4ever-project.org/wiki/display/docs/RO+SRS+interface+6 10 Implementation repositories at https://github.com/wf4ever : rosrs, workow-runner , Stability-service-API , epnio, wf-ro, Collaboration-spheres and portal.
From Workows to Research Objects that, alongside semantic metadata, comprise RO structures, minting identiers (URIs) as required; (iii) Maintenance: adding and removing RO resources whilst ensuring consistency with metadata and manifests, and managing user identities and accounts and their relationships to ROs.
The second, myExperiment [
Lifecycle services support the dynamic nature of workow-centric RO resources over time. Publication and Archival are preservation states for which an RO must be preserved: the RODL service allows creation of a duplicate with a new state (live, snapshot, or archived) through the RO Evolution API. Using the roevo ontology it also captures versioning metadata of the subsequent relationships between these ROs, the history of which can be retrieved through the API. The Workow Runner service is built upon Taverna workow server, providing remote workow execution with each run captured as an RO. Numerous workow runs generate many ROs, so their lifespan may be short should an RO require longer-term preservation it is exchanged between the Runner and RODL services using the ROSR API as implemented by both components.
Data Management and Analysis services provide an extension layer that augments Storage and Lifecycle capabilities: that generate, maintain and provide access to added-value data derived from, or related to, RO resources. Four services are implemented within the current Wf4Ever Toolkit: (i) Checklist Evaluation performs an assessment of an RO passed by its URI (and retrieved from either a local disk or from a remote service implementing the ROSR API) against a minimum information model 11 for purposes of completeness, repeatability, executability, etc.; (ii) Stability Evaluation is a derivative service, monitoring the Checklist Evaluation over time as a measure of whether an RO can maintain its original purpose whilst constituent resources change or become unavailable; (iii) the Recommender service uses keyword, content-based, collaborative ltering, and social network approaches, returning recommended users, ROs, and their aggregated resources; (iv) WF-RO Transformation is a service that, given a Taverna t2ow workow bundle, generates or updates an RO encapsulating that workow, extracting workow description using the wfdesc and roevo ontologies respectively, and storing these resources in the RODL (or other service implementing the ROSR API).
Access and Usage Clients allow users to interact with ROs and the
services enabled by them. Some, such as Collaboration Spheres [
RO Manager [
In this paper we have shown how the RO model provides a suitable basis for interoperability within a service-based architecture for management of scientic workows, and outlined a number of implemented services from the Wf4Ever Toolkit that support scientic preservation via this mechanism of interchange the RO model, its extensions, the REST APIs built around it, and the services and clients that implement and use these APIs. The architecture and Toolkit are a work in progress, co-evolving with user requirements as rst-hand experience is gathered. With foundation services in place and our approach validated we will build upon the exibility of the RO model and the simplied client development process aorded by our APIs; to further enhance and streamline the scientist’s experience both through targeted applications that assist a specic task, and the continued RO-enabling of myExperiment with Wf4Ever services.