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]

Olaf,

I agree with all the substance of your comments here.

What I didn't say before was that I intended to also add something along the 
lines that the mechanisms for third party discovery could also be used by the 
original provider.  It was more of a document organization change than a 
substantive technical change.  I'll bear this in mind when I re-work this later 
today.

#g
--

Olaf Hartig wrote:
> 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 Thursday, 4 August 2011 08:41:57 UTC