Re: PROV-WG Reminder: Review PAQ before FPWD vote

Hi Luc,

A quick response in-line. The others I have to think about.

Luc Moreau wrote:
> 1. ISSUE-52/iSSUe-55
> I still believe that 4.2.2 should be on an equal footing to section 2.
> Section 2 can only work in some limited circumstances when a provenance
> uri exists.
> Section 4.2.2 is really the only mechanism that is workable when
> provenance is produced by a party different to the resource provider.

I thought this was addressed. I rewrote the text of Section 2 on 
accessing provenance information to treat them as equals. Section 3 
allows for for different parties to provide provenance. The resource 
provider.

> 2. ISSUE-79
> I still don't have a good understanding of the expected properties for
> provenance-uri and provenance information.
> - can we expect the same provenance information for every dereference of
> a provenance-uri? If not, we must say it.
> - if resource changes, does provenance uri change?

I think this can be clarified. We expect some provenance information but 
that provenance information may change. We do not define the contents of 
the provenance information. Essentially, it's up to the implementer to 
decide what provenance information is there.

>
> 3. The specification should not make any assumption about the nature of
> entity-uri, which may be or not be http Uris. Prov-dm document gives an
> example with uuid Uris. The http get/head approach may not always work.

Hmm... this may throw a wrench in the whole thing.....

>
> 4. While it is reasonable to mention entity-uris in headers as resource
> representations are passed in get responses, a provenance service should
> not be limited to entity uris.  We need to be able to retrieve the
> provenance of activities  too.
>
> It would also be reasonable to access the content of an account.
Ok, then should we use record-uris? This should encompass everything in 
the PROV-DM, right?

>
> 5. Section 6. There doesn't seem to be a mechanism to control the amount
> of provenance returned. A viewer for prov may want to obtain provenance
> at a maximum distance of 3 hops. Sparql is not a satisfactory solution
> for clients which request XML or json.
Why not? SPARQL returns both XML and JSON serializations. I'm reticent 
to define a provenance specific graph traversal protocol when the W3C 
already defines a graph traversal query language.


>
> 6. Section 6. Paul's recent blog on simple provenance is showing the
> limitation of the http head approach. When a get/head of resource
> ex:post returns a provenance-uri it may not be his provenance since Paul
> may not have control over this service. Why refer to this method in
> seCtion 6?

I don't see this as a problem. You are describing the provenance of 
someone else's resource, which is possible but should we recommend it?

Received on Tuesday, 15 November 2011 11:15:08 UTC