Skip to end of metadata
Go to start of metadata

This page an accummulation of notes about Wf4Ever architecture and implementation topics that we thiunk could benefit from face-to-face discussion at the Manchester project plenary meeting, with partcular view to integrating our developments for the M20 software deliverable.



RO access

To integrate our work across the project, we should have a common way to access
RO content and metadata. The ROSRS API (1a,1b) is a point of departure, but see
also (1c) I've had discussions with various people about the relationship to
linked data (1d, 1e) and the role of relative URI references (1f). Do we need
to clarify aspects of RO "identity" (e.g. if I make a local copy of an RO, is it
the same RO?), and how these are reflected in system interfaces.

To involve: all developers, architects, +Jun?


See also RO identification & Versioning

Realization of service APIs

The project architecture sets out that service interfaces will be based on REST
and linked data principles but (as I recall) says little about how these will be
realized (other than focusing on a "model" as the key element for exchanging

In showcase 47 we implemented a service interface using a "service document", a
new link relation, a URI template and a description of data formats to be
exchanged. Is this the kind of service interface we want to press for? This
also has a bearing on the RO access discussion.

To involve: all developers, architects


Mixing information from Taverna

We currently face an integration blocker because we cannot easily get workflow information from Taverna as RO annotations using the wfdesc vocabulary. Stian has done some work on this, but there seem to be some problems, and it seems this is something that will affect our ability to build meaningful ROs for a significant number of ROs.

This also seems to affect exchange of information between Wf4Ever and myExperiment.

What we do have is Taverna ?Wf-RO transformation service which is running in sandbox and is used in myExperiment import wizard in RO Portal. It currently generates wfdesc annotations based on Stian's code. It will additionally generate roevo annotations based on worfklow history.

To involve: all developers working with RO and Taverna data.

Which RO model version?

Currently, as far as I am aware, software tools are working with the v0.1 RO
vocabulary specification, which has since been updated. Should we be aiming to
converge our M20 deliverable on the more recent versions (4c, 3a), and if so
what plan to we have for updating our existing test data?

Should be be thinking about APIs to support alternative format versions?

To involve: all developers working with RO and Taverna data. +Architects?

ROEVO and versioning

(as discussed in ARCH telecon 2012-05-24 - need to add notes)


ROEVO and provenance

I'm not sure if this discussion is a must-have for M20 deliverables, but I think
it would be very valuable if we can reconcile ROEVO and provenance. The key
issue is that a description of RO evolution is a form of provenance
information. As such, it seems it really should be structured and expressed
using the core model of provenance (star) information, even if the specific
relationships it uses are not part of standard provenance vocabularies.

Currently, ROEVO has a structure that does not relate to provenance. One of the
particular issues I think needs to be clarified is how we can reconcile
sometimes divergent user views of RO evolution with a common underlying
technical representation of this evolution. I think there are some discussions
we've had that suggest a clearer consensus about the role and use of ROEVO might
be achieved if the provenance core model were used to structure ROEVO information.

(star) The core provenance model, as appears in all (thgat I have seen) of the
existing provenance proposals, makes explicit the role of some kind of activity
or process in the derivation of new artifacts from old ones. This "reification"
of the activity provides a place to apply more detailed descriptive metadata as
needed, and in particular to associate the role of agents who control, guide or
influence the actvities.

To involve: (Raúl, Oscar, Graham, Jun, Marco, Pique, ...)

Authentication & Authorization project-wide

(from Raul)

(from my last email)
I was coming back to one of the comments from our reviewers during our
It was about the authentication/authorization.
Due to the nature of our architecture, where we have different (possible
distributed) services, she mentioned to take a look at the IGI/delegate
authorization approach.
I think it would be a good idea to specify/state our approach in this
Delegation is, in fact, needed to achieve scalable distributed
authorization, but it can be implemented by extending a bit our current
proposal described in
So, currently we use openID, which allow users to be authenticated in a
decentralized manner.
Similarly, we are using oauth for authentication, which could be used for
delegated authorization

Of course these are mainly used by RODL at the moment, but with the
upcoming services, I was hoping to get feedback from the rest of you, are
you fine with this approach, do we need to enforce some adoption policy
for the wf4ever services. This will be useful towards the M20
deliverables, where we will need to have a clear idea of the toolkit.

Wf4Ever Toolkit phase I

(from Raul)

(part of thursday first slot)

Also from my last email, I would like to have the table filled by the
plenary (I guess I will contact each responsible person individually).
This discussion would fit in the first slot of Thursday and having this
information beforehand will be very useful.

So, besides discussing what software components will be part of the
toolkit for this deadline, we can discuss how are we going to deliver it.
Apart from having a running instance in the sandbox, are we providing some
downloadable toolkit package.

Cross-project integration

(Maybe this is the same as the previous point, but I'm putting it here to be sure)

I assume that the M20 deliverable should show integration of components developed across the project.  What is this implementation to look like - what will be the front-end, how will services connect it it, etc.

  • No labels