I've read the links supplied, but I'm not sure I understand the purpose/context of these URI's....
On Tue, May 11, 2010 at 1:53 AM, Stian Soiland-Reyes <[email protected]> wrote: > Hi! > > We've come to the stage where we realise we need to specify a common > scheme for identifying items in a workflow. In particular we need to > be able to identify processors, ports, workflows, but also workflow > data and provenance/execution elements, like a particular iteration. > 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? > This is important for the SCUFL2 [1] work, and also for the > Semantification [2], in addition we think this should be consistent > with RDF exports of provenance data. 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. 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? > > > I've drafted a quick suggestion of Taverna URI templates in [3]: > > For example: > > http://ns.taverna.org.uk/2010/workflows/0f5e83c1-bbb5-42e7-9ba3-438f645d3d17/processors/getPage/inputs/url > > identifies the input port "url" for the processor "getPage" in the > workflow which internal identifier is > "0f5e83c1-bbb5-42e7-9ba3-438f645d3d17". (you may find the workflow at > [5]) > > > You can therefore make statements such as: > > <http://ns.taverna.org.uk/2010/workflows/7cbda4a8-21ca-4d22-83d5-9d0959ab1e5b/processors/getPage/inputs/url> > blah:expectsType xsd:anyURI ; > dc:description "The URI to fetch page comic links from" . > I'm assuming these URI's are not the entry point, they look like they are part way though some client-server exchange. Can't you not care about any of that and just say clients must construct URI's as described here: http://tools.ietf.org/html/draft-zyp-json-schema-02#section-6 e.g. one day a server gives the client a template such that the client constructs: http://ns.taverna.org.uk/2010/workflows/7cbda4a8-21ca-4d22-83d5-9d0959ab1e5b/processors/getPage/inputs/url 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) http://ns.taverna.org.uk/7cbda4a8-21ca-4d22-83d5-9d0959ab1e5b/processors/getPage/inputs/url/2010/workflows/ etc. As for the 'expects' I think you can achieve that with the HTTP 1.1 spec and media-types, etc. plus all the other advantages and reasons why RESTful usually gets implemented over HTTP. > The Semantification of Taverna [2] work will allow you to attach such > mini-graphs to the individual items in the workflow, so that they can > be preserved with the .t2flow / .scufl2, and exported as RDF. Kept as > relative annotations on the ports/processors/etc. they would also be > preserved when the workflow ID changes. (The ID changes every time an > edit is done on the workflow). I'm not upto speed on semantification, so I suspect I don't understand the above. I've seen all the talk about it, but I've yet to make sense of it. Ideally an API client would be indifferent to another technology coming along. If it changed your object (workflow) in some fundamental way.... in which case it seems you should just be considering a new version of the API, and new versions of the client if you can't continue to give/receive the old format - so really you want clients to know about versions from the outset. But that is too trivial, so I suspect you meant something deeper by the 'semantification of Taverna'? > > > This is also interesting for SCUFL2, as one of the workflow output > formats could be RDF, and identifers are also needed for internal > linking, like when specifying bindings, datalinks, conditions and > annotations. > This sounds like you are thinking about having more than one media type on the client side, but that is a RESTful notion which is an API approach that imposes constraints - its not clear those constraints have been adopted. Or are you thinking in terms of server-side's typed resources, but again the idea that the server is opaque to the client is a constraint.... ;) > > We are very interested in comments and feedback on this draft, in > particular if you are involved in the Semantic Web/LinkedData/RDF > community or the RESTful Web Services community. You may either leave > a comment on the wiki page [3] (if you are a registered wiki user) or > (preferably) respond to this email to the taverna-hackers list [4]. > As mentioned I think how you tackle these issues really is determined by the API approach(constraints) you adopt. E.g. XML-RPC, WSDL, WADL, RESTful etc would like result in very different suggestions and solutions. I have some more questions but will send those tomorrow. Best wishes > > [1] http://www.mygrid.org.uk/dev/wiki/display/developer/SCUFL2 > [2] http://www.mygrid.org.uk/dev/wiki/display/developer/Semantification > [3] http://www.mygrid.org.uk/dev/wiki/display/developer/Taverna+URI+templates > [4] http://www.taverna.org.uk/about/contact-us/ > [5] http://www.myexperiment.org/workflows/824 > > -- > 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/ > -- πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα [The fox knows many things, but the hedgehog knows one big thing.] Archilochus, Greek poet (c. 680 BC – c. 645 BC) http://wiki.hedgehogshiatus.com ------------------------------------------------------------------------------ _______________________________________________ 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/
