- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 17 Jan 2013 14:50:29 +0000
- To: Paul Groth <p.t.groth@vu.nl>
- CC: Ivan Herman <ivan@w3.org>, Provenance Working Group WG <public-prov-wg@w3.org>
On 17/01/2013 11:50, Paul Groth wrote: > -1 > > I think there needs to be a discussion on this. I think removing the > suggestion makes it more complicated to implement for someone wanting to > put together a simple provenance service. I dispute this claim. In my experience, the added complexity when providing a service is trivial, and in some cases it may actually make the service implementation simpler. Let us suppose that one has a service that already implements the "suggestion". The only additional thing required to support the full REST interface is to serve a static service document indicating the URI template. Nothing else is required. This additional requirement should be trivial to implement in just about any web application framework - it is in the ones I've used. It could even be just a static page on a web server that references the actual live service. Supporting content negotiation adds a little more complexity, but as long as there is a "must understand" RDF format for clients, that can be skipped. It may be that there are alternative forms of URI construction that are easier for a service to interpret in particular web application environments: as long as the URI format can be described using a URI template, the service is free to use that format, and publishes a corresponding service description. ... The flip side of all this is client side complexity. Here there is a price to play: the client must be able to retrieve the service document, extract the URI template and use it to construct a URI. There are easy-to-use URI template libraries for many languages. In my work, I have also implemented a URI template web service that allows even a simple BASH script using CURL to perform URI template expansion. So while this does add some client complexity, I don't think it needs to be overwhelming. #g -- > > However, there are other blocking objections that we need to address first. > > Graham and I need to collect all issues and then prioritise them. > > Paul > > > On Thu, Jan 17, 2013 at 12:29 PM, Ivan Herman <ivan@w3.org> wrote: > >> >> On Jan 17, 2013, at 11:36 , Graham Klyne <GK@ninebynine.org> wrote: >> >>> Ivan, >>> >>> On 11/01/2013 12:08, Ivan Herman wrote: >>>> - In 4.2, the text says "according to the following convention" and >> then example uses &target=.... This suggests that the &target=... is the >> usual convention that implementations should use. But this is not the case. >> However, 4.1.1. says that the URI template defines what is used, ie, I can >> have a service using a different convention, say, &resource=.... I believe >> this should be made clearer in the text. >>> >>> Well spotted! This somewhat reflects an earlier compromise that may now >> be less suitable (if indeed it ever was suitable). As such, I think it may >> be more than editorial and should be discussed. >>> >>> Originally, the compromise was to "fix" the URI form so it could be used >> directly in simple cases, and to provide the service description and URI >> template to allow a RESTful (HATEAOS)style of interaction. >>> >>> Now that the same link relation is used for both direct-access and >> query-access to provenance, I think the option of short-circuiting the >> HATEAOS interaction of retrieving the service document and using that to >> determine the URI to use for retrieving provenance is no longer sensible. >> As such, I propose to drop mention of the convention in the text and >> clarify that a client should use the URI template in from the service >> document. >> >> +1 >> >> Ivan >> >>> >>> #g >>> -- >>> >>> >>> >>> >> >> >> ---- >> Ivan Herman, W3C Semantic Web Activity Lead >> Home: http://www.w3.org/People/Ivan/ >> mobile: +31-641044153 >> FOAF: http://www.ivan-herman.net/foaf.rdf >> >> >> >> >> >> > >
Received on Thursday, 17 January 2013 14:51:25 UTC