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

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 07:54:49 UTC