W3C home > Mailing lists > Public > public-prov-wg@w3.org > August 2011

Re: PROV-ISSUE-79 (provenance-uri-contract): what is the contract associated with provenance-uris [Accessing and Querying Provenance]

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Fri, 26 Aug 2011 09:28:57 +0100
Message-ID: <EMEW3|f666121bc71e382a5a8d4f5fa9854b15n7P9UL08L.Moreau|ecs.soton.ac.uk|4E575949.8060400@ecs.soton.ac.uk>
To: public-prov-wg@w3.org

Waw! Graham,

This is really a crucial point. Did you have in mind that provenance 
were not changing over time?

It's probably one of the key reasons where we take opposite views on the 

I was working on the assumption that provenance resources were changing.

I have two use cases where provenance of something is changing:
- in PASOA, we used to have asynchronous recording of provenance, hence,
   some assertions might have been asserted, but
   might have not been recorded.  When
   you were querying provenance, you could therefore get different results.
- Second, in this WG, we have not defined yet (and I think we should) 
what we
   mean by obtaining the provenance of something.  Does it include all 
the uses
   of that thing?  I guess that provenance includes the backward graph, 
but does it also include
   the forward graph?
   If the latter, (and this is not unreasonable), than provenance of a 
resource changes
   as the resource is being *used*.

So, I believe that the provenance of something can change.
But really, I don't know what your notion of a provenance resource is.  
We could define it as
static or dynamic  (even if provenance of something can change).  The 
for implementation are substantial though.

If a provenance resource is not supposed to change over time, the 
provenance-uri points to a "frozen provenance",
for a given resource in a given state.  To implement this, you would 
require provenance services
to have a form of "roll back" to previous states, to return the 
provenance as it existed in previous
points in time.  Do we really want that?


On 26/08/11 08:48, Graham Klyne wrote:
> On 26/08/2011 04:51, Paul Groth wrote:
>> Hi Graham,
>> I think the important thing is that we don't say anything about how 
>> provenance
>> information must be maintained. That is to say that the provenance 
>> information
>> referred to by a provenance-uri may change over time.
>> If I add some more detailed provenance information about a resource, 
>> I can still
>> use the same provenance-uri.
>> Is that correct?
> Good question.
> I think the important feature of provenance information (hence 
> provenance resources) possibly even a defining feature, is that if it 
> is ever true, it is always true.
> Also, valid inferences based on information from provenance resource 
> must remain valid indefinitely.
> I think the implications of this are:
> (a) it may be OK to add true information
> (b) it would not be OK to remove information
> But I think the whole issue of explicitly allowing a provenance 
> resource to vary may turn out to be a rathole.  I'd rather focus on 
> the essential properties and let the rest sort itself out.
> #g
> -- 
>> Graham Klyne wrote:
>>> On 23/08/2011 12:05, Provenance Working Group Issue Tracker wrote:
>>>> PROV-ISSUE-79 (provenance-uri-contract): what is the contract 
>>>> associated with
>>>> provenance-uris [Accessing and Querying Provenance]
>>>> http://www.w3.org/2011/prov/track/issues/79
>>>> Raised by: Luc Moreau
>>>> On product: Accessing and Querying Provenance
>>>> The PAQ document indicates that provenance information (sometimes 
>>>> referred to
>>>> as provenance resource) may change over time.
>>> Where does it say that? If it does, I think it's a mistake.
>>> What's the implication for the provenance-uri? Is the provenance-uri 
>>> a cool
>>> URI? I think it is not, but this should be made explicit. There are 
>>> also
>>> further issues.
>>>> Generally, what is the "contract" associated with this 
>>>> provenance-URI? How
>>>> long should the server be able to serve this URI? It's particularly 
>>>> important
>>>> for dynamically generated pages.
>>> IMO, any contact for longevity of retrievability of the resource is 
>>> outside
>>> scope of the spec. We can'#t mandate indefinite availability, and 
>>> nothing else
>>> would make any sense.
>>> #g
>>> -- 
>>>> Let us consider a provenance store, in which provenance assertions 
>>>> gets
>>>> accumulated. Let us consider a static resource, r, but over time, 
>>>> what we
>>>> know about r changes, so it may have different provenance 
>>>> information p1 and p2.
>>>> If r is accessed, and a provenance-uri is returned, and 
>>>> dereferenced a first
>>>> time, we obtain p1.
>>>> If r is accessed again, are we expecting to get the same 
>>>> provenance-uri, or a
>>>> different one if provenance has changed?
>>>> Now, let us consider r as a dynamic resource. If r changes between 
>>>> the first
>>>> and second access, is the same provenance-uri supposed to be returned?
>>>> If it does not change, how do we ever have a guarantee that the 
>>>> provenance
>>>> information obtained corresponds to the resource representation we 
>>>> obtained?
Received on Friday, 26 August 2011 08:30:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:08 UTC