On Tue, Nov 22, 2011 at 19:21, Mark <[email protected]> wrote: > The SADI plug-in does this (for SADI services); however I don't think the > semantic type information is written into the SCUFL... would be useful!
We wanted Scufl2 to allow the anchors to attach any such annotation. However most services don't kindly provide much information about their semantic types, and even if they did, "Swissprot ID" from serviceA might be called "swissprot-id" in serviceB. However, within "families" of services such typing can easily be established. We are workbench-wise planning to use this in Taverna 3, building "components" which wrap services with rich semantic typing and any needed shims to work within a "component family". (Think of these as a collection of pre-collapsed nested workflows which you should never need to look inside). > w.r.t. the broader conversation about representation of SCUFL2 - I agree > 100% that it should be RDF for the sake of being able to attach > annotations to any part of the workflow without breaking a "schema" (in > fact, reversing that argument convinces me that Schema-based approaches > are simply wrong, since then you break validation by doing "the right > thing" and annotating!). Mm.. My idea was that one could do the XSD-thing if wanted (and did not know much RDF), or go free-form RDF, but then remove the xsi:type attribute in the top element. However this means readers of scufl2 can't really be certain about getting an XSD-document and might have to fall back to parsing RDF anyway - from this argument, then perhaps the XSD should only be a helper-thing for write only? (As RDF/XML allows so many ways to say the same thing, we almost certainly won't get any of the RDF libraries to output RDF/XML that just happens to conform to the XSD) > v.v. the serialization of that RDF, I'm ambivalent... human-readable (e.g. > Turtle) would be my preference, I guess, but I don't really want to ever > read a workflow document by-eye anyway, I only want to visualize it and > manipulate it using tools... so whatever RDF serialization is supported by > the most tools might be the real deciding factor. Yes, and that is why I (with regrets) decided to go for RDF/XML instead of Turtle, because libraries for Python and Ruby did not seem to be quite up to all aspects of Turtle, like using a relative @base. But perhaps that's another aspect that can be revisited. In the current Workflow Bundle spec you can write the RDF/XML according to the XSD (which enforces where your nested resources are expressed, etc). Any additional annotations which don't affect execution should go in a separate (free-form RDF/XML) annotation file within the bundle like "annotations/myexperiment.rdf" (annotations inserted by myExperiment), where it can reference say the scufl2:InputProcessorPort <../workflows/HelloWorld/processor/blast/in/sequence> This also mean that you can add annotations without changing anything else in the bundle, ie. just doing a zip add - which would be ideal to attach auxiliary non-executable information which don't affect the execution of the workflow bundle. (and hence don't require the bundle to get a new ID) > I have no problem with distributing multiple files as a .zip - it's pretty > standard, na?? It seems to be possible to deal with from within most environments - although I've not yet tried from JavaScript. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ 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/
