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

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

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Tue, 15 Nov 2011 13:15:19 +0000
Message-ID: <EMEW3|fa6eb716c10015e09df67579e6accd73nAEDFM08L.Moreau|ecs.soton.ac.uk|4EC265E7.4080902@ecs.soton.ac.uk>
To: Paul Groth <p.t.groth@vu.nl>
CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
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 
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 
There are still people using SQL ... I think ;-)

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


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


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:04 UTC