Re: PROV-ISSUE-618 (pingback-in-prov-aq): Should pingback be described in PROV-AQ? [Accessing and Querying Provenance]

On 03/02/2013 11:26, Paul Groth wrote:
> So the gist is to just post back hasProvenance links...
Roughly (by my interpretation), yes, but I would say not strictly hasProvenance 
w.r.t. the original resource.  I.e. the link is not necessarily to provenance 
*about* the resource, but provenance of entities in whose history the resource 
appears.  But the values posted would typically be values of *some* 
hasProvenance link.

#g
--

>
> Paul
>
>
> On Fri, Feb 1, 2013 at 6:04 PM, Timothy Lebo <lebot@rpi.edu> wrote:
>
>> Stian,
>>
>> I still need to do a careful review of your comments, but would not be
>> opposed to your idea to "trim down" what can be posted.
>> By only accepting the values of the hasProvenance links that could appear
>> elsewhere, it aligns with the rest of the document much more cleanly.
>> It also avoids the authoritativeness issue that you point out.
>> And, if "my server" wanted to offer up a small RDF graph around the
>> "downstream" resource, then it could go fetch and select what it wants to
>> re-host on its own.
>>
>> So, can we resolve the issue by restricting what can be POSTed to the ping
>> back URI (to only values of hasProvenance)?
>>
>> Best,
>> Tim
>>
>>
>>
>> On Feb 1, 2013, at 11:48 AM, Stian Soiland-Reyes <
>> soiland-reyes@cs.manchester.ac.uk> wrote:
>>
>>> On Thu, Jan 31, 2013 at 6:50 PM, Timothy Lebo <lebot@rpi.edu> wrote:
>>>> Following up from today's call, what is Stian's proposal?
>>>> I must admit that I have been following each of his feedback emails.
>>> Well if you followed those emails, it should be clear! ;-))
>>>
>>> The proposal is from my review at
>>> http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0121.html
>>>
>>>
>>> My proposal is that the pingback works like a 'send me a URL' thing,
>>> just like a pingback in a blog is. I don't pingback to your blog
>>> service with a copy of my new blog post, I just give you the link,
>>> which your blog might or might not publish.  So the link in this case
>>> would be a provenance-URIs <http://example.com/some-provenance.ttl> or
>>> a provenance-query-service <http://example.com/sparql>, to be
>>> associated with some target-URI (read prov:Entity)
>>> <http://elsewhere.example.org/resource>.   If this is honoured, then
>>> subsequent requests to find provenance for
>>> <http://elsewhere.example.org/resource> (as in section 2) would
>>> include the new links.
>>>
>>>
>>> The good thing is that now this also provides a way for third-parties
>>> to provide additional data that can be returned by the provenance
>>> service described in first half of PROV-AQ - and so just like the
>>> first half does not detail how the actual provenance data is retrieved
>>> or got there in the first place, but mainly provides links to other
>>> resources which return the provenance or let you query it; then the
>>> second half should be about how to add those links. Currently there
>>> are no way to add those links.
>>>
>>> The original proposal the pingback service seems more like a "Please
>>> store this provenance for me" service - which would go counter to the
>>> disclaimers in the first half about how you should place different
>>> trust on provenance from different sources (the hosted 3rd party
>>> provenance would appear authoritative if it comes from the same server
>>> as the resource) - and not have an obvious link to the lookup.
>>> Obviously this raises many other problems such as updates, alternative
>>> representation of the same resource, metaprovenance, Date headers,
>>> etc.  If you just want to do "Please store and host this resource
>>> (RDF) for me and give me a URL" - then there are many existing methods
>>> to do so - the simplest being HTTP PUT on the desired URI, a more
>>> elaborate one could be AtomPub or even.. ) out of bands with WebDAV
>>> (ugh) and (S)FTP.
>>>
>>>
>>>
>>>
>>> Here is my alternative proposal for this section:
>>>
>>>
>>> (Same blurb about finding prov:pingback)
>>>
>>>   C: HEAD http://acme.example.org/super-widget HTTP/1.1
>>>
>>>   S: 200 OK
>>>   S: Link: <http://acme.example.org/pingback/super-widget>;
>>>            rel=http://www.w3.org/ns/prov#pingback
>>>    :
>>> Each resource MAY be associated with one or more prov:pingback services.
>>>
>>>
>>> A client MAY post a pingback request to any or all of the returned
>>> prov:pingback services.
>>>
>>>
>>>   C: POST http://acme.example.org/pingback/super-widget HTTP/1.1
>>>   C: Content-Type: text/uri-list
>>>   C:
>>>   C: http://wile-e.example.org/contraption/provenance
>>>   C: http://wile-e.example.org/another/provenance
>>>
>>>   S: 204 No Content
>>>   S: Link: <http://wile-e.example.org/contraption/provenance>;
>>>            rel=http://www.w3.org/ns/prov#hasProvenance;
>>>            anchor=http://acme.example.org/super-widget
>>>   S: Link: <http://wile-e.example.org/another/provenance>;
>>>            rel=http://www.w3.org/ns/prov#hasProvenance;
>>>            anchor=http://acme.example.org/super-widget
>>>   S: Link: <http://acme.example.org/pingback/super-widget>;
>>>            rel=http://www.w3.org/ns/prov#pingback;
>>>            anchor=http://acme.example.org/super-widget
>>>
>>>
>>> This client request above indicates that the two provenance-URIs at
>>> wile-e.example.org contains provenance mentioning
>>> http://acme.example.org/super-widget or its target-URI (-- either
>>> forward or backwards, we don't know).
>>>
>>> The client MAY include provenance query services which can describe
>>> the target-URI by including the corresponding {prov:hasQueryService}
>>> Link headers. The anchor MUST be included, and SHOULD be the
>>> target-URI of the resource which this pingback service belongs to,
>>> unless the submitted query service would expect a different target-URI
>>> to describe the given resource.
>>>
>>>   C: POST http://acme.example.org/pingback/super-widget HTTP/1.1
>>>   C: Link: <http://wile-e.example.org/sparql>;
>>> rel="http://www.w3.org/ns/prov#hasQueryService";
>>> anchor="http://acme.example.org/pingback/super-widget"
>>>   C: Content-Type: text/uri-list
>>>   C: Content-Length: 0
>>>   C:
>>>
>>> In the above example, the client did not submit any provenance-URIs
>>> and the URI list is therefore empty.
>>>
>>> The client MAY similarly include {prov:hasProvenance} Link headers to
>>> specify a different anchor. The provenance-URIs of those headers MUST
>>> also be included in the content if the POSTed Content-Type is
>>> {text/uri-list}.
>>>
>>>
>>>
>>> The pingback service MAY resolve the submitted URIs to validate and
>>> check the provenance data, however reasonable care should be taken to
>>> prevent malicious use of the pingback service for attacks such as
>>> distributed denial of service (DDoS) and cross-site request forgery
>>> (CSRF).
>>>
>>> The server MAY, immediately or at a later time, include the submitted
>>> *provenance-URI*s in responses to subsequent request to the provenance
>>> service for the target-URI. (insert usual blurb about not trust on
>>> such provenance)
>>>
>>> The server SHOULD include a self-referential prov:pingback Link
>>> header, which MUST include the anchor for the target-URI this pingback
>>> service corresponds to. This serves the purpose for the client to
>>> verify it has submitted a pingback to the correct service, in case it
>>> has followed an untrusted prov:pingback Link header. The client MAY
>>> for this purpose POST an empty text/uri-list to avoid side effects.
>>>
>>>
>>> The server SHOULD indicate immediate acceptance by including the
>>> corresponding {prov:hasProvenance} {Link} headers for the accepted
>>> *provenance-URI*s. If all submitted provenance-URIs have been
>>> immediately accepted, the server SHOULD respond with HTTP status {200
>>> OK} or {204 No Content}.
>>>
>>>
>>>
>>> If server acceptance is pending for any of the submitted URIs, for
>>> instance because the provenance-URIs are being validated or due to be
>>> approved by a moderator, the server SHOULD respond with HTTP status
>>> {202 Accepted}, and only include corresponding {prov:hasProvenance}
>>> {Link} headers for those provenance-URIs that have been immediately
>>> accepted.
>>>
>>> The server MAY respond with {401 Unauthorized} and standard
>>> {{WWW-Authenticate}} headers if authentication is needed. The server
>>> SHOULD respond with {403 Forbidden} if for any reason it refuses to
>>> accept one or more of the submitted provenance-URIs or
>>> provenance-service-URIs. If some URIs were accepted, but others were
>>> refused, the server SHOULD respond with {403 Forbidden} and include
>>> generated prov:hasProvenance and prov:hasQueryService Link headers for
>>> the immediately accepted URIs.
>>>
>>>
>>> (The above needs to be cleaned up so that it talks equally about
>>> prov:hasProvenance and prov:hasQueryService in the error handling -
>>> and also to separate better the protocol and the example).
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Stian Soiland-Reyes, myGrid team
>>> School of Computer Science
>>> The University of Manchester
>>>
>>>
>>
>>

Received on Monday, 4 February 2013 09:58:05 UTC