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

So the gist is to just post back hasProvenance links...

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