Re: PROV-ISSUE-53 (sparql-query-is-overkill): can't we have a lighter method to retrieve provenance-uri, given a document uri? [Accessing and Querying Provenance]

Hello,

On Friday 29 July 2011 08:44:14 Graham Klyne wrote:
> OK, I'll work on something like that and transfer and adapt the SPARQL
> stuff to section 4 (provenance querying).

I wouldn't remove that from Section 3.4. Instead, we should understand it as 
an alternative to a REST based API.

However, the issue for a client then might be the following: Given a 
resource/document URI u_1 and the URI u_2 for a third-party provenance 
registration service; we want to ask that service for a provenance URI u_3 
that refers to provenance information about u_1. How do we decide whether
u_2 has to be accessed as if it were a SPARQL endpoint or as if it were the 
REST API?
 
> I'll assume that only the simplest discovery case is needed; i.e. have URI
> of entity, what to get URI(s) for its provenance.
> 
> (The other case that used other forms of identification to locate
> provenance will get dropped from 3.4, since that was really just showing
> how to exploit SPARQL capabilities)

That's exactly what I liked about the SPARQL based mechanism. The provider of 
a third-party provenance registry service may support such, more complex 
search patterns and, thus, set itself apart from other registries that only 
support simple queries with a single prov:hasProvenance triple pattern (or the 
REST API equivalent thereof). It's a business opportunity.

Cheers,
Olaf

> 
> #g
> --
> 
> Reza B'far wrote:
> > As an implementer, I strongly agree with Luc.  REST-base http protocol
> > with minimal payload is a much more likely first option.  Also, it's not
> > necessary that provenance is stored in a traditional notion of a
> > database.  I guess folks call many various persistence mechanisms these
> > days a database, but some of these (say simple files, LDAP, etc) map mug
> > easier to a simple API with just GET's or something like that.
> > 
> > Usage of SPARQL is still very limited to sem web specialists (compared to
> > simple REST/http/minimal)
> > 
> > Best
> > 
> > On Jul 28, 2011, at 8:04 AM, Graham Klyne <GK@ninebynine.org> wrote:
> >> SPARQL might well be considered overkill if you had to implement it from
> >> scratch.  But there are now many SPARQL toolkits that doesn't seem to
> >> be such an issue.  If you do a REST interface, it would likely be
> >> backed by some kind of database, so not so much complexity saving
> >> there.
> >> 
> >> I think there's a case for defining a simple REST API that might be
> >> implemented over a SPARQL store using an LDA
> >> (http://code.google.com/p/linked-data-api/wiki/Specification) toolkit,
> >> or by other means.  It's not clear to me if that would receive more
> >> developer attention.  Maybe for the time being we might define both
> >> (REST and SPARQL) and review them as we approach candidate
> >> recommendation.  (Oh, but that won't apply to the PAQ, will it?)
> >> 
> >> (BTW, SPARQL is not inherently non-RESTful for simple queries.)
> >> 
> >> #g
> >> --
> >> 
> >> Provenance Working Group Issue Tracker wrote:
> >>> PROV-ISSUE-53 (sparql-query-is-overkill): can't we have a lighter
> >>> method to retrieve provenance-uri, given a document uri? [Accessing
> >>> and Querying Provenance] http://www.w3.org/2011/prov/track/issues/53
> >>> Raised by: Luc Moreau
> >>> On product: Accessing and Querying Provenance
> >>> Isn't it too onerous to require third parties to provide sparql
> >>> endpoints, simply to answer the query illustrated in
> >>> http://dvcs.w3.org/hg/prov/raw-file/default/paq/provenance-access.html
> >>> #third-party-services  (give the provenance-uris for this resource)?
> >>> Stian had suggested a REST service to answer this query, encoding the
> >>> URL as an argument passed to the service. I had outlined a variant
> >>> with GET instead of POST. Some implementers may not use an RDF
> >>> serialization of provenance, and therefore, it would be good to have a
> >>> non-SPARQL approach for finding a provenance URI.

Received on Monday, 1 August 2011 19:30:40 UTC