- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 13 Feb 2013 10:07:29 +0000
- 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