W3C home > Mailing lists > Public > public-openannotation@w3.org > February 2013

Re: Bodies translations: use cases and thoughts

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Wed, 13 Feb 2013 10:07:29 +0000
Message-ID: <CAPRnXtnCBOuq6+01cu=wSMZVvXsTmZzd3cr2fDwLmPJ0-59DEw@mail.gmail.com>
To: Tommaso Teofili <teofili@adobe.com>
Cc: Paolo Ciccarese <paolo.ciccarese@gmail.com>, public-openannotation <public-openannotation@w3.org>
On Wed, Feb 13, 2013 at 8:04 AM, Tommaso Teofili <teofili@adobe.com> wrote:
> Does any other member have use cases about translations?

I have translations between representation formats.

Below is just a summary of our usecase here, without any particular
solutions suggested.

If I upload a Taverna 2 workflow to our workflow preservation service,
it will convert it to Taverna 3 (future-proofing), and also extract
from a general workflow description (wfdesc). You could consider the
equivalent that you upload a .doc, it's converted to .docx and .html.

So theour aggregation (ORE) will have 3 resources which in a way are
all translations or versions of each other, and currently we have not
related them particularly well, except added a tiny pav:importedFrom
relation in a standalone annotation body with original and translation
as targets.

You could picture that on resolving a resource by HTTP then there
could be content negotiation to get the alternate representations
instead (we don't have this for user-contributed resources yet).
pav:importedFrom is not a strong enough statement for this, but
perhaps dcterms:hasFormat could work.

But many of the annotations that are then done by the user, like
descriptions, comments, rating etc. in general apply to all of these
resources, or in a way, apply at the more abstract FRBR Expression and
Work level rather than at Manifestation level. Some would apply at
Manifestation level, like "I can't load it", "This is the one I ran",
but generally the users do not consider any difference between the
file and what the file defines.

We have in our wfdesc description opted for the more Expression-level
equivalent of a workflow which is independent from the workflow
definition, ie. if  you upload the same definition at two different
servers, both would use the same URN-like URIs for the workflow and
its components in the wfdesc translation - we formally distinguish
between the abstract Workflow and the concrete WorkflowDefinition.

To relate the two we've had to just make our own
wfdesc:hasWorkflowDefinition from the Expression to Manifestation -
but this means that when you are looking for annotations it gets quite
tricky because they could exist at both levels, and you have to
resolve one annotation body to find the wfdesc:hasWorkflowDefinition
link, and then look for annotations again on the other side.

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Wednesday, 13 February 2013 10:08:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:03 UTC