On 12 July 2013 17:09, Markus Plangg <[email protected]> wrote: > Are all annotations stored in separate files in a workflow bundle? Is it > right, that the individuals reference each other using relative URIs and > so all these files could be loaded simultaneously and still make sense > (e.g. to query over the resulting RDF)?
Yes, as long as you get the base URI right when loading those files into the RDF store. The safest way is to generate an app:// URI [http://www.w3.org/2012/sysapps/app-uri/] e.g. app://c13c6f30-ce25-11e0-9572-0800200c9a66/ (but with a new UUID!) as the base, and then append the relative path within the ZIP file to the RDF file that is being parsed, e.g. "annotations/blah.rdf" to form app://c13c6f30-ce25-11e0-9572-0800200c9a66/annotations/blah.rdf. This makes it easy to use app://c13c6f30-ce25-11e0-9572-0800200c9a66/ as a base again later to regain the relative URIs. Within the workflow Bundle, a 'global base URI' is given, say http://ns.taverna.org.uk/2010/workflowBundle/8781d5f4-d0ba-48a8-a1d1-14281bd8a917/ , this can be used instead of the app:// trick for forming absolute URIs for workflow elements - as anyone reading the same bundle would get the same URIs and those would be the URIs you would find in say a workflow run provenance trace. Note that we don't write those absolute URIs because that base (or more correctly, the UUID within it) must change for any workflow modification, and we don't want to necessarily invalidate all annotations -- thus we use relative URI references when saving. Annotations don't generally reference each other, although they could - but refer to workflow elements (such as a processor or an input port) within the workflow definition, which is typically something like "../workflows/Hello_world/processor/greet/in/name" relative from <annotation/blah.rdf>; resolving to say <http://ns.taverna.org.uk/2010/workflowBundle/8781d5f4-d0ba-48a8-a1d1-14281bd8a917/workflows/Hello_world/processor/greet/in/name>. I have also planned to extend the current scufl2-wfdesc tool to also extract all the annotations in a single graph - this would then have done the 'merging' required already, but you could no longer see annotation metadata such as when a description was made. > Alternatively I would read the annotations via > Annotation.getBodyStatements() and do the "querying" to find certain > ports, .. pragmatically. Note that I am planning to remove the getBodyStatements() method (which was easy to write out, but not so easy to read in without RDF libraries) and just expose the RDF resources as 'files' - thus you can parse them with your favourite RDF library - there will just be a getBody() method. > I'd like to avoid to parse the t2flow myself, especially when I could > use the API instead. Of course! > Regarding the time schedule, it would be great to have access before the > end august. So if it is possible to do this first without much overhead, > that would be great. OK, I will have a go through the following two weeks and keep you posted. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718 ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/about/contact-us/ Developers Guide: http://www.taverna.org.uk/developers/
