W3C home > Mailing lists > Public > public-prov-wg@w3.org > January 2013

Re: prov-aq review for release as working draft (ISSUE-613)

From: Ivan Herman <ivan@w3.org>
Date: Thu, 17 Jan 2013 12:29:59 +0100
Cc: Paul Groth <p.t.groth@vu.nl>, Provenance Working Group WG <public-prov-wg@w3.org>
Message-Id: <3FA9358D-526F-4D18-BB22-AC37B007E580@w3.org>
To: Graham Klyne <GK@ninebynine.org>

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 11:30:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:27 UTC