Re: PROV-AQ: How to indicate SPARQL endpoint for provenance (ISSUE 609)

Graham,

On Nov 29, 2012, at 3:07 PM, Graham Klyne <gklyne@googlemail.com> wrote:

> Tim,
> 
> You raise several issues here. In this response, I want to focus on your final point about the URI template.
> 
> I think the uri template, or something that serves a similar purpose, should be mandatory to use.


I agree, if "something that serves a similar purpose" is simply left as a "service description [preferably in RDF]".
I have no problem with the AQ offering the uritemplate, I just oppose it being held so prominently as to seem to be a requirement.


> This is because without this, the service is constrained on the uris it may use for delivering provenance descriptions, which rather flies in the face of REST architecture principles.

I'm not a REST blackbelt, but it's my understanding that REST principles leaves the power of URI construction solely with the server, and it's up to the client to "follow it's desire" to realize the application state by HTTP verbing the URIs it's given.


> What I think we should be aiming for is maximum decoupling between client and server. 


We could increase the decoupling by eliminating the uritemplate, but I'm not suggesting we go that far.


> 
> When you point your browser at Amazon, or an online banking site, the browser knows nothing about the nature of the site.

> These are quite different sites, Yet you are able to interpret the links offered, and navigate to the functions you wish to perform, based on information provided by the service to which you connect.


Yes, and all of that was done without uri templates. It was done by me and my browser HTTP verbing on the URIs that I found.


> 
> To my mind, link relations and URI templates do for linked data what html pages and hyperlinks do for human-facing web applications.


Yes, minus the uri templates. With them, you're eroding the server's ability to control (and, upgrade) the application state.
To me, URI templates are a device of Web 2.0 development and it not appropriate for linked data and true, mature REST.


> In principle, an application should be able to follow an arbitrary link to a site, and from there figure out if there's anything it can do there.

Again, this can and should be done without using a uri template. It is done by the iterate server-client request cycle that exchanges URIs (as your shopping example does).


> 
> So for me (and others), the link relations and service descriptions lie at the heart of a properly Web-friendly service interface.


+1 to link relations and service descriptions.
-10.0 to demanding uri templates as the service description, and leaving it in such a prominent position that it appears to be a requirement.
+1 to offering uri templates as a means of a service description (though, personally, I'd recommend people don't use it).

Regards,
Tim


> Against this background, I want to think some more about your comments re the SPARQL endpoint, and also take account of feedback from the LDP group.
> 
> #g.
> 
> 
> Timothy Lebo <lebot@rpi.edu> wrote:
> all,
> 
> On Nov 29, 2012, at 1:36 PM, Graham Klyne <Graham.Klyne@zoo.ox.ac.uk> wrote:
> 
>> We decided to drop the merely advisory material about how to use SPARQL, and leave that to the FAQ.  But discovery of a SPARQL endpoint got forgotten in the change (I think it was never really specified previously).
>> 
>> I think the cleanest solution would to to introduce another link relation
> 
> 1)
> 
> I'm not fond of another link relation just to point to one specific service technology.
> 
> To handle "discovery of SPARQL endpoints" I think we should instead combine:
>     A) GET on service gives RDF description.  (as already stated)
>     B) http://www.w3.org/TR/sparql11-service-description/
> 
> to return:
> 
> <service-URI> a prov:ProvenanceService, sd:Service ;
> additional vocabulary from B should be used further describe the service.
> The fact that <service-URI> is a sd:Service indicates that it is a SPARQL endpoint.
> 
> 
> 2)
> 
> The following citation seems to be inconsistent.
> 
> [SPARQL-HTTP]
> Chimezie Ogbuji. SPARQL 1.1 Service Description. 2011, Work in progress. URL: http://www.w3.org/TR/sparql11-http-rdf-update/
> 
> 3)
> 
> In http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html#provenance-service-description
> I do not think the prov:provenanceUriTemplate property should be so prominent.
> 
> The first example:
> 
>   <service-URI> a prov:ProvenanceService ;
>     prov:provenanceUriTemplate "service-URI?target={+uri}" .
> should be trimmed to:
> 
>   <service-URI> a prov:ProvenanceService ;
> 
> with prov:provenanceUriTemplate being described as an OPTIONAL description in subsequent discussion (as it stands now, it appears to be required).
> This, too, is an assumption on how a service could be accessed.
> 
> -Tim
> 
> 
> 
> 
> 
> 
>> for a SPARQL query endpoint (but to not get into details of how to formulate the queries, other than to say that they are presented via SPARQL HTTP protocol, and executed over provenance formulated as RDF according to PROV-O).
>> 
>> I'll raise an issue for this.
>> 
>> #g
>> --
>> 
>> Tracker, this is issue 609
>> 
>> 
>> On 29/11/2012 15:59, Paul Groth wrote:
>>> It's a good question. I wonder if we can somehow role this into
>>> provenance-service url?
>>> 
>>> Paul
>>> 
>>> 
>>> On Thu, Nov 29, 2012 at 4:30 PM, Cresswell, Stephen <stephen.cresswell@tso.co.uk
>>> <mailto:stephen.cresswell@tso.co.uk>> wrote:
>>> 
>>>    Hi,____
>>> 
>>>    __ __
>>> 
>>>    It still seems to me appropriate for PROV-AQ to include some method by which
>>>    publishers of a resource can indicate a SPARQL endpoint for provenance
>>>    queries.____
>>> 
>>>    There was some discussion on this about a year ago, but it got stuck on
>>>    unresolved questions about named graphs, and doesn’t seem to have made it
>>>    into the document.____
>>> 
>>>    __ __
>>> 
>>>    Has there been a decision not to accommodate this, or is it still a
>>>    possibility?____
>>> 
>>>    __ __
>>> 
>>>    http://lists.w3.org/Archives/Public/public-prov-wg/2011Dec/0067.html____
>>> 
>>>    http://lists.w3.org/Archives/Public/public-prov-wg/2011Dec/0040.html____
>>> 
>>>    http://lists.w3.org/Archives/Public/public-prov-wg/2011Dec/0039.html____
>>> 
>>>    __ __
>>> 
>>>    Stephen Cresswell____
>>> 
>>>    __ __
>>> 
>>>    This email is confidential and may also be privileged and/or proprietary to
>>>    The Stationery Office Limited. It may be read, copied and used only by the
>>>    intended recipient(s). Any unauthorised use of this email is strictly
>>>    prohibited. If you have received this email in error please contact us
>>>    immediately and delete it and any copies you have made. Thank you for your
>>>    cooperation.
>>> 
>>>    The Stationery Office Limited is registered in England under Company No.
>>>    3049649 at 1-5 Poland Street, London, W1F 8PR
>>> 
>>> 
>>> 
>>> 
>>> --
>>> --
>>> Dr. Paul Groth (p.t.groth@vu.nl <mailto:p.t.groth@vu.nl>)
>>> http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
>>> Assistant Professor
>>> - Knowledge Representation & Reasoning Group |
>>>   Artificial Intelligence Section | Department of Computer Science
>>> - The Network Institute
>>> VU University Amsterdam
>> 
>> 
> 
> 
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.