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

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

From: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
Date: Wed, 02 Jan 2013 14:49:11 +0000
Message-ID: <50E448E7.2000808@zoo.ox.ac.uk>
To: Timothy Lebo <lebot@rpi.edu>, Paul Groth <p.t.groth@vu.nl>
CC: "Cresswell, Stephen" <stephen.cresswell@tso.co.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Tim,
Paul,

Following an extended discussion with Erik Wilde, I'm now persuaded that an new 
link relation is not the best way to go for SPARQL endpoints.

I the absence of a clear alternative proposal, I propose to stick with RDF (in 
any of its syntaxes) for the service description.

I do think we want an easy way to distinguish different service implementations 
in an RDF service description, and my preference for this would be the rdf:type 
of the described service resource.

Thus, if we have a provenance service that supports both the templated and 
SPARQL interfaces, I would anticipate a service description along these lines:

[[
<#template> a prov:ProvenanceService ;
     prov:provenanceUriTemplate "http://www.example.net/prov?target={+uri}"
     .

<#sparql> a sd:Service ;
     # (description per http://www.w3.org/TR/sparql11-service-description/)
     sd:endpoint <http://www.example.net/sparql/> ;
     sd:supportedLanguage sd:SPARQL11Query ;
     sd:resultFormat <http://www.w3.org/ns/formats/RDF_XML> ,
                     <http://www.w3.org/ns/formats/Turtle> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_XML> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_JSON> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_CSV> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_TSV>
     .
]]

I think it's easy to see how this can generalize to accommodate alternative 
services if such are introduced later.

In practice, I anticipate that different service URIs (indicated by multiple 
provenance service link headers) would each implement a single access mechanism, 
so the multiple options within a single service description as shown above are 
not a requirement.

Tim: you indicated previously that prov:ProvenanceService should apply to *all* 
forms of provenance service.  I haven't proposed that above, but it would be 
possible to have this as a generic class for all provenance services, with the 
above example then becoming, say:

[[
<#template> a prov:TemplatedService, prov:ProvenanceService ;
     prov:provenanceUriTemplate "http://www.example.net/prov?target={+uri}"
     .

<#sparql> a sd:Service, prov:ProvenanceService ;
     # (description per http://www.w3.org/TR/sparql11-service-description/)
     sd:endpoint <http://www.example.net/sparql/> ;
     sd:supportedLanguage sd:SPARQL11Query ;
     sd:resultFormat <http://www.w3.org/ns/formats/RDF_XML> ,
                     <http://www.w3.org/ns/formats/Turtle> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_XML> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_JSON> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_CSV> ,
                     <http://www.w3.org/ns/formats/SPARQL_Results_TSV>
     .
]]

If you're OK with this, I'll plan to update PROV-AQ accordingly (but I can't 
guarantee to have it done until after next week, as I'm travelling to a meeting 
then.)

#g
--

On 29/11/2012 18:53, Timothy Lebo 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
>>
>>
>
>
Received on Wednesday, 2 January 2013 14:50:50 UTC

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