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

Hi Paul,
Further comments in line.

On 11/15/2011 11:12 AM, Paul Groth wrote:
> 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.
>    

Yes I saw that. I think that section 2 should really consist of
two subsections 2.1 and 2.2 contrasting the two approaches.


>    
>> 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.
>    

This needs to be said, to avoid any doubt.

The implementability of the scheme for provenance stored in databases
should also be thought through.

>    
>> 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.....
>
>    

There was even a suggestion of blank nodes being used for entity 
identifiers.
I am not supportive of this, but I definitely wouldn't want to restrict URIs
to http URIs.

>> 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?
>
>    
I think it's better.
>> 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.
>
>
>    

I am definitely not requesting a new graph traversal protocol. I just
want to be able to control the amount of provenance I receive in a client.

Isn't SPARQL assuming an rdf store implementation.  It means that there 
is no
solution for people implementign natively provenance in non-rdf 
technologies.
There are still people using SQL ... I think ;-)

I am suggesting something an extra parameter depth, such as:

  "http://example.info/provenance_service/provenance/?uri={uri};?depth={depth}"

>> 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?
>
>
>    

Not necessarily different person. Your blog example could have been
extended, with another perspective on the same resource, which would
have required a new URL to be minted for this new entity:

ex:post prov:wasDerivedFrom ex:report.

ex:post2 prov:wasGeneratedBy ex:reviewProcess.
ex:post2 wasComplementOf ex:post

The new URL ex:post2 can it be resolved by a GET? Wouldn't it result in 
a 404?
Can a provenance link be included in the http response, even if 404?



Luc


-- 
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 13:15:55 UTC