W3C home > Mailing lists > Public > public-prov-wg@w3.org > April 2013

Re: [PROV-AQ] Editors' working copy updated

From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Date: Fri, 05 Apr 2013 14:13:28 +0100
Message-ID: <515ECDF8.3000608@zoo.ox.ac.uk>
To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
CC: Paul Groth <p.t.groth@vu.nl>, W3C provenance WG <public-prov-wg@w3.org>

Thanks for your feedback.  I've updated the document in response to most of your 
points, but there are a couple that I didn't feel warranted changes.  More 
detailed responses below.

I've also done some work on the pingback examples and associated description to 
try and make them clearer (but no substantive changes).

On 03/04/2013 13:27, Luc Moreau wrote:
> Hi Graham and Paul,
> I did a quick review of the document.  Here are a few comments.
> Key points:
> ----------
> 1. Term "constrained resource".
>    I suggest renaming to "specialized resource", to better align
>    with data model. Nowhere dm has a notion of "constrained".
I find the phrase "specialized" (as opposed to being a "specialization of ...") 
conveys implications of intent or purpose that are not apposite here.  I think 
that talking of "specialized resources" could be more confusing, hence this 
term.  The connection with "specialization" is in the text.

(No change applied.)

> 2. Example 11. The role of the anchor is a post to a  pingback URI is unclear.
>  What's the purpose of this anchor? Isn't it redundant?
>  Is it mandatory for the anchor specified by the client,
>  to be the same uri as the one original requested with a GET?
>  If Yes, what is the expected behaviour of the service when the anchor differs.
It's a SHOULD: that's what the text says.  Per Link: specification, if the 
anchor is not specified, the "context URI" would be the pingback URI, which is 
probably not very useful.

But I agree the intent isn't entirely clear in the example:  I've expanded the 
explanation following example 13 (was 11): " Here, the pingback client has 
supplied a query service URI, but did not submit any provenance-URIs and the URI 
list is therefore empty. The |Link:| header indicates that the resource 
|http://acme.example.org/super-widget/provenance| contains provenance 
information relating to |http://acme.example.org/super-widget| (that being the 
URI of the resource for which the pingback URI was provided). "

>   If the Service returned an anchor, with the has_provenance link,
>   can/should the anchor provided by the client when posting to the
>   pingback url be the same?
The client is not constrained: it may indicate any provenance information it 
chooses.  This is indicated by the next paragraph, which I've expanded slightly 
to make the point clearer:  " The pingback client /MAY/ include extra 
|has_provenance| links to indicate provenance records related to a different 
resources, specified with a correspondingly different anchor URIs."

I've also added an example (12) for this case.
>   Can the client mint new uris that it posts as anchors to the pingback uri?
That's not forbidden, but I can't see why that it would be useful. More likely 
IMO would be to mint new URIs in the provenance, and relate them (e.g. using 
PROV vocabulary) to the original resource, then use the original resource URI in 
the pingback links

If this needs further clarification, I'd suggest creating an FAQ entry.

> 3. I don't understand what the incentive is for a service to add a pingback 
> link to http responses?
>   Likewise, I don't understand what the incentive is for a client to post to a 
> pingback uri?
>   The document does not specify any expected behaviour in response to the post 
> to a pingback uri.
>   Therefore, it's misleading to say it helps with discovery. It only
>   helps with discovery if the information posted in to a pingback uri,
>   is shared in someway, but we don't know how it's shared.
I see the lack of documented incentive as a feature not a bug - I think we've 
heard from developers that they do have incentive to use this mechanism.  It's 
in the nature of well-crafted standards that developers can do things with them 
that were not necessarily anticipated by the designer.  I also see the lack of 
expected behaviour as a feature, not a bug.  Indeed the spec *explicitly* says 
the behaviour of a pingback recipient is unspecified.  This is, by design, an 
enabling mechanism, not a service specification.

I was going to suggest changing "helps with discovery" to "may help with 
discovery", but I can't find such text in the spec.  Pingback is described as a 
"discovery mechanism", which I think is a perfectly fair description.  As such, 
it clearly "helps with discovery" only if it is actually used, so I don't see 
anything misleading here.

> Other remarks:
> -------------
> 4. Make the spec a working group note, and update sotd.  No need of ref to 
> editor's draft.
I agree these changes should be done before publication - I see them as part of 
the staging process.

I propose to leave this to be done one the WG has formally agreed to release it 
as a NOTE.  While it's still WIP, I find the editors draft reference to be 
sometimes useful.

I've removed the "Third public working draft" text, which is clearly redundant.
> 5. section 1.2: this specification should not make reference to validity. The 
> mechanisms presented
> here do not rely on validty.
OK, changed.  ("valid" here was meant in a descriptive rather than a formal 
sense, but I've dropped use of that term.)

> 6. section 1.4.  I agree that in a LOD-style, target-URI shoudl return what 
> you specify.
>    But, this is not the remit of this specification, I would drop this entry.
>    Whereas, for the other URIs, it is the remit of this specification to say what
>     provenance-uri, service-uri, pingback-uri should dereference to.
I'm OK with dropping this, but I thought it was something I was asked to include.

I've added a TODO note to drop it, and will wait to see if anyone objects.

> 7. Section 3: Thanks for adding the note, just before 3.1. It would be
> better to move it, just before 3.3. Otherwise, it is not possible to 
> understand it.
OK.  (Also added cross-ref at the end of section 3.3)

> 8. Go through all examples, and "instantiate" the resource:
>    http://example.com/resource -> http://example.com/resource123

> 9. In example 3, could you add a further example, where the server returns
>    a Link has_provenance after redirect, but provides no answer.
>    This said, is it the intent, that the target-uri is to be understood as
>     http://example.com/resource123? Why not the redirect uri?
I don't understand the request/question here.  What do you mean by "provides no 

In example 3, the target-URI is 
http://example.com/resource123/20130226/content.html, as indicated by the Link: 
anchor parameter.

Ah, did you mean "provides no anchor"?

I'll add some commentary to the example..
This example indicates a provenance record at 
|http://example.com/resource123/provenance/|, which uses 
|http://example.com/resource123/20130226/content.html| as the target-URI for the 
requested resource. If the |anchor=| parameter were to be omitted from the 
|Link:| header, the indicated target-URI would be 

> 10. section 4.1.1  which which -> which
> 11. section 5, 2 paragraphs after example 10: i don't understand
>   " the target-URI of the resource to which this pingback service belongs ..."
Yes, I did wonder about that.  I'll try and make it clearer...

The client /MAY/ also supply |has_query_service| links indicating provenance 
query services that can describe the target-URI. The anchor /MUST/ be included, 
and /SHOULD/ be either the target-URI of the resource for which the pingback URI 
was provided (from the examples above, that would be 
|http://acme.example.org/super-widget|), or some related resource with relevant 
provenance. For example:

> On 25/03/2013 17:23, Graham Klyne wrote:
>> Re: https://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html
>> My apologies for not getting this done by last Thursday.  I believe I've 
>> incorporated all the changes noted at the 2013-03-14 teleconference, and that 
>> the document is now ready for final WG review.
>> See also:
>>   http://www.w3.org/2011/prov/meeting/2013-03-14
>>   http://www.w3.org/2011/prov/track/products/5
>> Per original timetable 
>> (http://www.w3.org/2011/prov/wiki/WorkplanTillFinalPublication#prov-aq), I'm 
>> hoping to have all final comments in by 20130404 (a week Thursday).
>> #g
>> -- 
Received on Friday, 5 April 2013 17:24:16 UTC

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