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

On 11/12/2012 13:36, Timothy Lebo wrote:
> Graham,
>
> On Nov 29, 2012, at 3:07 PM, Graham Klyne <gklyne@googlemail.com
> <mailto: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.

Yes, the server should be in control of its URI space.

The URI template allows it to communicate its URI space usage to a client 
application in actionable form.  It's a standard mechanism that I believe has 
been created for just this purpose.

>> 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.

I disagree.

Without the URI template, a client must have prior knowledge of the server's URI 
usage, and the server is no longer free to change such usage without breaking 
the client(s) that are endowed with such knowledge.  That would increase, not 
decrease coupling.

This is exactly why I think the URI template SHOULD be a central element of the 
interface.

The only alternative I can think of would be for the service to provide a list 
of *all* of the resources for which it has provenance, along with the 
corresponding provenance URI.  That would (a) potentially be very inefficient, 
and (b) result in a far more complex service document

So, in this respect, a URI template serves as a kind of "hyperlink schema", 
allowing the construction of otherwise very large hypermedia documents that 
would be needed to guide a REST interaction.

>>
>> 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.

But it also involves you, the user, interpreting the text in the HTML pages that 
provide context for these links, and filling values into forms that effectively 
parameterize subsequent requests.

This isn't available for automatic application-to-application interactions, 
which is what we're talking about here.

>>
>> 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.

Disagree - see above.

>> 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).

Apart from providing an exhaustive listing (see above), or using a predefined 
URI structure, I don't see how this could apply to the scenario of an 
application automatically retrieving provenance for an arbitrary named resource 
from a REST service.

#g
--

>>
>> 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 <mailto:lebot@rpi.edu>> wrote:
>>
>>     all,
>>
>>     On Nov 29, 2012, at 1:36 PM, Graham Klyne <Graham.Klyne@zoo.ox.ac.uk
>>     <mailto: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
>>         <http://www.w3.org/TR/sparql11-http-rdf-update/>. 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>
>>>>     <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>
>>>>     <mailto:p.t.groth@vu.nl>)
>>>>     http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
>>>>     <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.
>

Received on Sunday, 16 December 2012 13:14:15 UTC