Re: Request for Review of TAG AWWW 2nd LC Draft.

[Bcc'd TAG to avoid further cross-posting]

I have read (quickly) over Pats annotated version at 
http://www.ihmc.us/users/phayes/2004-PatHayesComments.html

He has a number of larger concerns, some (apparently) small 
concerns/questions of clarification including those he calls out after 
his signature line below and some smaller editoral suggestions.

Pat's most significant comments seem to arise around section 2.1 - 2.3 
inclusive:

In 2.1 Pat observes that it is "Absolutely false" to require the 
association of a URI with a resource in order to "make or refute 
assertions about it." I agree and this is a good catch!

Larger concerns:

1)  Association of URI with non-Information resources (my paraphrase)... 
How is that accomplished? [wrt to Section 2.1"GPN Identify with URI", 
2.1.1 URI Allocation]

2) Sense of Identity: "Access" v "ReferTo or Name"  and "Unambiguous 
Reference" [wrt section 2.2 URI/Resource relationship, 2.2.2 URI Collision]
Much of what we say makes sense when we are speaking of what we 
currently call "information resources", where identify is taken to mean 
access and he finds the "Assign distinct URI to distinct resources" 
reasonable in that circumstance. However, when we are speaking more 
generally of resources as 'things" which may not have web accessible 
representations he takes signficant isssue with a great many things that 
we say. In that circumstance the problem he has with the "Assign 
distinct URI to distinct resources" is that requires 
considerable/unreasonable precison of reference in order to distinguish 
between distinct resources. He cites an example based on Mount Everest 
in response to "2.2.2 URI Collision".

3) Identification, "Naming and Take on Meaning" [also in 2.2]
This is the area Danny Weitzner commented on. Pat's comment is fuller. I 
think the issue is again centred around unambiguous reference and the 
'hole' we have 'dug for ourselves' (see comment under "2.2.2 URI 
Collisions'").
Pat's advice is to speak only of "identify/association" and despense 
with talk of  "names and meaning".

Interestingly in the 2nd para of his comments after "Assign distinct 
URI..." he says: "One qualification to the above: it is reasonable to 
require this kind of unmambiguous distinctness when we expect that URIs 
will be dereferenced, i.e. used to access things, and the thing accessed 
is what the meaning is. .... But access is one thing, and 
naming/reference is something else. Probably this wouldnt matter, if it 
were not for the fact that semantic web formalisms use URIs to refer 
with no presumption of accessibility, which rather forces one to make 
the distinction more carefully. "

4)  Sameness resources: [wrt 2.3.2 representation reuse and 3.6.1 URI 
persistence]
Suggest explicit mention of time varying nature of resources. Remarks on 
the inability to distinguish between a series of 'different' resources 
associated with a given URI and resource with time-varying representations.

5)  Request more significant defense of the "Data - metadata 
inconsistency" principle [Section 3.4]


Regards

Stuart
[now in a hurry to get to the meeting...]
--









Stuart Williams wrote:

>
> At Pats request I am fowarding the content of a message I received 
> from him in response to my request that he review our 2nd LC WD.
>
> Best regards
>
> Stuart
> -- 
> ----Original Message-----
> From: Pat Hayes [mailto:phayes@ihmc.us]
> Sent: 28 September 2004 21:50
> To: Williams, Stuart (HP Labs, Bristol)
> Subject: Re: Request for Review of TAG AWWW 2nd LC Draft.
>
> Stuart, greetings and apologies for the lateness of this reply. (I 
> could plead mitigating circumstances, but I was already late when Ivan 
> came.)  I know time is tight and I have no right to hold things up any 
> longer.  Although I am still not entirely happy,  for W3C procedural 
> purposes you may register my acceptance of this as an adequate 
> response to my original objection.  Stop reading at this point if you 
> like.
>
> The document is greatly improved and I can now understand it 
> coherently, and I appreciate the work that must have gone into getting 
> it into this state. However, it is still ambiguous in a few places, 
> most notably in sections 2.2 (which is blatantly circular and misuses 
> terminology in confusing ways) . In particular, the sections you cite 
> in your message seem to indicate that you intend the unqualified use 
> of the word 'resource' to be the wide sense (my 'D' in the C/D 
> contrast, i.e. anything that may be referred to), whereas the bulk of 
> the text in the document seems to imply rather clearly that you have 
> in mind the narrower C sense, in particular where the text remarks or 
> presumes without explicit comment that resources have states and can 
> be accessed by Web protocols.  Section 2.2.3 seems to be a 
> sketch/draft of a way to resolve this tension quite nicely, but the 
> idea is not developed.
>
> The central example has been re-worded very nicely to make its meaning 
> clear (the resource is the on-line weather report) but it is still not 
> clear if the analogous alternative example, where the resource would 
> be the actual weather, would be a valid example: certainly the quote 
> from section 2.2 seems to suggest this; but much of the rest of the 
> discussion in the text seems inconsistent with it.
>
> The remark that this document is not intended to cover all SWeb uses 
> is very helpful, and I think was a wise insertion, and the 
> clarification of the meaning of 'representation' is good.
>
> Rather than produce another vast email, I have annotated the text with 
> comments drawing attention to the places where this ambiguity seems to 
> still arise, and making a few other comments, most of them 
> reiterations of points I made when commenting on the earlier draft. 
> The result is at
>
> http://www.ihmc.us/users/phayes/2004-PatHayesComments.html
>
> in case it might be useful.
>
> Pat
>
> A few editorial matters you might want to check:
>
> In Sec 2.3 'URI' is used as a plural, elsewhere 'URIs' is used.
>
> Section 2.6 talks of 'some view on representations' What does this mean?
>
> Section 3.3.1, second paragraph seems to have some elision at the end 
> (may be only a missing period)
>
> Is an interaction unsafe if the agent is AT RISK of incurring an 
> obligation, or only in the case where the obligation is in fact 
> incurred? The glossary implies the latter but I think the former is 
> intended.
>
>
>> Pat,
>>
>> The TAG has been working to address some of the concerns that you 
>> raised in
>> [1] in response to our 1st last call on the the AWWW document [2].
>>
>> In particular, we now explicitly state that "We do not limit the 
>> scope of
>> what might be a resource", and we introduce a term for the class of
>> resources that can be interacted with via an exchange of 
>> representations -
>> "information resources". This is an attempt to resolve the 'C'/'D' sense
>> ambiguities in the use of terms that you identify.
>>
>> A couple of extracts from the now 2nd LC draft [2] below.
>>
>> We would appreciate your review of this draft and an indication of 
>> whether
>> you feel we have addressed the comments you made in [1].
>>
>> Best regards
>>
>> Stuart Williams
>> On Behalf of W3C TAG
>> -- 
>> [1]
>> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JanMar/1057. 
>>
>> html
>> [2] http://www.w3.org/TR/2003/WD-webarch-20031209/
>> [3] http://www.w3.org/TR/2004/WD-webarch-20040816/
>>
>> "2.2. URI/Resource Relationships
>>
>> By design a URI identifies one resource. We do not limit the scope of 
>> what
>> might be a resource. The term "resource" is used in a general sense for
>> whatever might be identified by a URI. A significant class of resources,
>> information resources, are discussed in Information Resources and
>> Representations [section 3.1]."
>>
>> and
>> "3.1. Information Resources and Representations
>> The term Information Resource refers to resources that convey 
>> information.
>> Any resource that has a representation is an information resource. A
>> representation consists logically of two parts: data (expressed in 
>> one or
>> more formats used separately or in combination) and metadata (such as 
>> the
>> Internet media type of the data)."
>
>
>
>

Received on Wednesday, 6 October 2004 07:15:12 UTC