Re: [PROV-AQ] Editors' working copy updated (final pass?)

Luc,

Following the vote last Thursday, I'm making one last pass to accommodate your 
responses where I can.  At this stage of the process, I shall be rather 
conservative with any further changes.

Modified text can be viewed at 
https://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html


On 09/04/2013 12:43, Luc Moreau wrote:
>
> 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.
In the absence of a better suggestion, I'll leave this as is.

>
>>
>>>
>>> 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).
>
OK, I've done that.

>
>>
>>>
>>>   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.
Does this help?:  I've slightly expended the text in front of example 13:

[[
The pingback client /MAY/ include extra |has_provenance| links to indicate 
provenance records related to a different resources, specified with 
correspondingly different anchor URIs. These /MAY/ indicate further provenance 
about existing resources, or about new resources (such as new entities derived 
or specialized from that for which the pingback URI was provided). For example:
]]

>>
>>>
>>> 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'm not going to risk adding further visionary material at this stage.  Overall, 
I think potential users are getting it, and we could add some more explanation 
in a FAQ.

>
>>
>> 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.
>
Ah, I see it now in the introduction.

I think "allowing for" hedges in a way that exactly acknowledges this point. No 
further change.

>>>
>>> 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'm hoping this will be my last pass before handing back to Paul for staging, 
who I think is better positioned to get these details right.

>>
>> 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.
Reviewing this again, I've taken a slightly different tack.  The entry remains 
in the table, but the "dereferences to" column now reads:

[[
Not specified (the URI is not even required to be dereferencable).
]]

...

No further responses.

Thanks for the feedback,

#g
--



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

Received on Friday, 12 April 2013 11:18:54 UTC