Re: [PROV-AQ] ISSUE-618: Should pingback be described in PROV-AQ?

On Mon, Mar 11, 2013 at 10:50 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:

> 1. I am not convinced by the "forward provenance/historical provenance"
> terminology. I think it's confusing,
>    in particular, given that all provenance is meant to be historical.

Yes, but it's future history from the point of the original.

For instance if I derive a new protocol from
http://users.ecs.soton.ac.uk/pg03r/Thesis.pdf then
http://users.ecs.soton.ac.uk/pg03r/ would not know about that. Others
who access Thesis.pdf might however be interested in finding this
information, so it would be an obvious easy solution to simply let the
origin know about it, in the same way that blogs have pingback
mechanisms to inform a blog that your blog post have been referenced
or responded to.

> 2. In the previous draft, I commented that we didn't have a good set of
> requirements for the design space
>    of the "old ping back" mechanism, that essentially allowed arbitrary
> recording provenance statements.
>    The argument still holds here, for the new mechanism.

Well, the server is free to choose what he does with the registered
pingbacks. It can inspect them to see if they are relevant/valid,
forward them to the admin as emails, link to them on a special
"related" resource, download it and put it on tape, instantly publish
the links in future PAQ requests, or even down to blindly importing
them to its provenance store. I would make it up to the applications
on how to do this.

For instance if I did a solution that did the instant-thing then
obviously I would want to add some kind of HTTP-level security to
restrict access to the ping-back resource. This is also a very good
example for when you should record provenance of provenance.


> 3. Terminology is forward/historical provenance is misleading. Really, it's
> provenance from two different
>     perspectives the consumer of an entity and its producer.

I agree. So it should just be about different starting points or
perspectives, really. Something like talking about "Provenance of X"
or "Provenance where X appears"


> 4.  There is actually  some precedent here.  Someone, called Paul Groth,
> discussed how a client and a service
>      can share the locations of the stores in which they respectively record
> provenance.
>      See section 4.3.3 http://users.ecs.soton.ac.uk/pg03r/Thesis.pdf

I guess Paul, as also one of the editors of PAQ, might want to chip in here. :)

Although a lot of As and Bs for my taste ;) this is essentially what
an architecture with PAQ would do, is it not?

The registration of VL1 is essentially what PAQ pingback enables.
Presumably VL2 is already known thanks to the discovery bit of PAQ.

The difference is that PAQ does not mandate this to happen, it only
deals with discovery and notification, and the stores are free to
decide to what extent they are going to trust the provenance that came
in a pingback.


>      In short, transposed to the PAQ, a get request could contain a
> provenance-uri/provenance-service-uri indicating where provenance
>       related to the current request can be found ...  linked to it, we will
> find the response, and any statement made by the client about
>       the retrieved resource.

This, sounding like a proposal #3, you would have to flesh out for me
to understand. Are you trying to suggest that a GET request should
have side-effects?


>       No more ping back, no more posting of provenance-uris to pingback uri,
> just make sure you exchange
>       provenance-uri/provenance-service-uri in both request and response.

I don't understand this. Do you mean I should GET a resource with a
Link header in my request, referring to a provenance bundle showing
how I have used the resource, before I got it?


>        I would argue that we cannot because we have not identified the
> requirements we are trying to address.

I thought the requirement was made clear in PAQ, although the
terminology of 'forward provenance' is a bit odd.

The requirement is for someone who has made a provenance trace
involving A somewhat (at any end of the chain), to inform the
publisher of A or provenance of A of the existence of this new trace.


> 6.  The rest of the PAQ was driven by the scenario
> http://www.w3.org/2011/prov/wiki/ProvenanceAccessScenario
>      I don't know what the  scenario is for ping back.

How about we see what the feedback is from the Note? If people use it,
then they obviously found a need for it. I know I am going to use it.


> 7. I don't think the group in the eleventh hour should try to define this
> scenario.

Do we need to? This is just a note. The pingback mechanism was suggested
in November 2012 after ISWC2012 discussions.

http://www.w3.org/2011/prov/track/issues/600

The modifications in my proposal was just to do it indirect by URI
rather than by the provenance bundle itself, which I would argue makes
it fit better in PAQ (which deals with locating provenance and
provenance services) than the original proposal.


> My recommendation is to:
> - put in our wiki Tim's original proposal for ping back
> - put in our wiki put in our wiki Stian's proposal for ping back
> - add a future work/other issues section to the PAQ with reference to the
> two wiki pages, a link to this issue.
> This will ensure that the work is not lost, and still referenced from the
> PAQ, while not formally part of it.

I think that is too drastic.

Why would you have trouble with it being in the note? It's not
required to be implemented. I thought notes were exactly for these
kind of things; putting it in the wiki is like making a note for the
note.


If you seriously are against it being in PAQ, then I would suggest
moving the section to a separate (very tiny) note rather than hide it
in the wiki.

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Tuesday, 12 March 2013 10:45:49 UTC