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

Hi Graham,

Thanks for the changes. Some comments below.

On 04/05/2013 02:13 PM, Graham Klyne wrote:
> Luc,
>
> 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.)

The term specialized may not be right. It's just strange to introduce a 
term that is not used in the data model at all.

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

The text helps.

Should you also "instantiate" super-widget to "super-widget123" (I find 
it confusing you were calling your resource differently here, and I wondered
if it had a special meaning).


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

It would be useful in the document itself.
>
>>
>> 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.

If you don't understand the whole vision and the reason why this is 
designed as it is and not differently,
it is difficult to see  how this can be used and made useful in practice.


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

The text said "allowing for discovery". I don't think that, per se, ping 
back allows for discovery.  It requires the pingback provider to
do something with the posted information, but this is not specified.

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

Please do them early, there are 13 documents to check!
>
> 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
> OK
>
>>
>> 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 answer"?

>
> 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 |http://example.com/resource123/content.html|.
> ]]

Yes, this clarifies, thanks.
>
>>
>>
>> 10. section 4.1.1  which which -> which
> Fixed.
>>
>> 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:
>  :
> ]]
>
>
Thanks,
Luc


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

-- 
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, 9 April 2013 11:43:56 UTC