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

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.  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.  What I think we should be aiming for is maximum decoupling between client and server. 

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.

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

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

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.