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

Hi Tim,

Your problem is that we suggest a particular url template. I think this is
important as it helps define what minimal content a provenance service
should support. It also helps developers figure out how they should expose
their provenance service.

regards
Paul


On Tue, Dec 11, 2012 at 2:36 PM, Timothy Lebo <lebot@rpi.edu> wrote:

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


-- 
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam