On Fri, May 14, 2010 at 12:30, Hedge Hog <[email protected]> wrote: > OK so you want an API that can CRUD (as appropriate) data representing > the attributes (ports, processors) of an object (workflow) and maybe > even methods? > Actualy creating the object from this data is beyond the API client, > as is executing, storing and tracking the object's life-time/history > aka provenance?
I'm sorry, I guess I should have clarified this confusion.. No, these are only furfilling the I of URI, just a consistent way to *identify* workflow items, for use in RDF statements. There will not (initially) be anything resolvable at those URLs, they function mainly as identifiers, like XML namespaces. There could possibly be a tiny autogenerated RDF document saying the things that are obvious from the URI, or there could be a lookup to myExperiment to see if there is a public workflow with that ID available, in which case we could redirect. No CRUD methods would be available, as workflows live on people's desktops, not on our web server. (I'm not sure the workflow designers would have appreciated that!) (You could build such a service though, inspired by the same scheme, but it would obviously have a different base URL) So the main purpose of these URIs is to specify a universal identifier so that you can make semantic statements about a workflow component in a particular workflow. It does not have to be resolvable, but of course it would be cool if it *could* be resolvable in the future for public workflows. Thus a http:// URL instead of something homebrew like taverna:// > Taverna workbench (one of potentially many clients) calls a X a > 'processor', some other client can call X somthing else? Or you > wanting to represent X, so these are agreed set of names. Yes, you could call it something else, like 'service', 'node', but in all cases you would agree that <http://ns.taverna.org.uk/2010/workflows/7cbda4a8-21ca-4d22-83d5-9d0959ab1e5b/processors/getPage> is that box called 'getPage' which you see if you open the workflow 7cbda.. in Taverna. Of course this would be much more interesting if we also give an RDF export of the workflow structure, where we could describe in Taverna-ontology what is 'getPage' and how it is connected to the other components of the workflow. That is on the plan together with our SCUFL2 work later, giving different representation of a workflow definitions, which should be more easily analysed or manipulated from external tools. > Specifically, are these SCUFL2, RDF, etc. all valid and complete > representations of the object of interest, or are you aiming for one > representation from which you can obtain what you need to build. For > example extract a SCUFL representation? SCUFL2 is aiming to be 'the' representation model, with serialisations as SCUFL2 XML, RDF, T2Flow and in compatible cases even Taverna 1 SCUFL. Currently 'the' representation is the instantiation in Java when loaded in Taverna, and the t2flow file format reflects this a bit too closely, which is one of the reason for forming the more detached SCUFL2 model. I guess your question is, in which of these representation is the component represented as <http://ns.taverna.org.uk/2010/workflows/7cbda4a8-21ca-4d22-83d5-9d0959ab1e5b/processors/getPage/> - and I would say all of them, if the representations claim to have the same workflow ID, they are claiming that they are the same workflow, which should produce the same results/effects. (assuming services return the same data) So we're kind of describing the *components in the workflow* as they are when opened and 'realized', not as serialized in a particular format. We are neither describing in what particular software, version or with which plugins the workflow is opened. In a way these identifiers (and statements using them) are quite useless without also having some kind of representation of the workflow, so you could anyway assume that the identifiers talk about items in the attached/related workflow definition. In our 'Semantification' work to allow attaching statements to such workflow components, these statements would be saved in the workflow representation itself, and so always bundled with the items that they are decribing. To compare with the classical FOAF problem of if <http://soiland-reyes.com/stian/#me> is talking about Stian as a person or <http://soiland-reyes.com/stian/#me> as a web page, we're here always talking about the 'real' object, not the serialization/representation. If you wanted to do that, you could say something like this using your own ontology: PREFIX xx: <http://example.com/2010/myTavOntology#> <http://www.myexperiment.org/workflows/824/download/fetch_today_s_xkcd_comic_841305.t2flow?version=1> xx:t2flowSerializationOf <http://ns.taverna.org.uk/2010/workflows/0f5e83c1-bbb5-42e7-9ba3-438f645d3d17/> . [] xx:inSerialization <http://www.myexperiment.org/workflows/824/download/fetch_today_s_xkcd_comic_841305.t2flow?version=1>; xx:serializationOf <http://ns.taverna.org.uk/2010/workflows/7cbda4a8-21ca-4d22-83d5-9d0959ab1e5b/processors/getPage> You could use xpointer or similar to give [] a proper URI. > the next day the server gets reconfigured and, in reponse to the same > client request, hands out a different template and the same client > constructs (a contrived reordering) As there is no server, I don't think we need to consider this template scenario. I would however, try to write up the suggested URI scheme as URI templates, like http://ns.taverna.org.uk/2010/workflows/{workflowId}/processors/{processorName}/inputs/{portName} -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ _______________________________________________ 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/
