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

Hi Graham and Paul,

I unfortunately don't have time to give it a deep read-through before 
Thursday.
However, after a first scan, I still have a number of issues. I am 
sending them
to you now as a single message. When I have completed a reading of the 
document,
I can raise them as specific issues, if appropriate (note that many were 
already
raised).




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.

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 question implementability of provenance-uri.
Isn't it the case that two compliant implementations of provenance-uri 
would be:
- constant uri (returning all provenance)
- canned query  (as describe for the rest service)
But, then, provenance-uri does not seem useful.

I can see a good usage when provider decides to cache/pre-compute
provenance information. But this seems to be a very specific usage of
provenance-uri.

How can an implementer with provenance stored in a database/triple
store usefully use the provenance-uri?

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.

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.

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.

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?

7. note is required for section 5. This conditional on development of 
prov-o.
But is it really the case we have such hasProvenance property?


8. As a client, how do I decide between 5.2 and 5.3 for a resource and 
provider discovered dynamically?

9. Shouldn't Section 3.3 also include a property hasProvenanceService.

10. ISSUE-75 doesn't seem to be tackled.





On 11/14/2011 08:11 PM, Paul Groth wrote:
> Hi All,
>
> This is a reminder to have a look at the current PAQ to see if you 
> support it going to FPWD.
>
> http://dvcs.w3.org/hg/prov/raw-file/default/paq/provenance-access.html
>
> Thanks,
> Paul
>
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Tuesday, 15 November 2011 10:45:39 UTC