- From: Dan Connolly <connolly@w3.org>
- Date: Fri, 09 Apr 2004 17:05:28 -0500
- To: Pat Hayes <phayes@ihmc.us>
- Cc: John Black <JohnBlack@deltek.com>, public-sw-meaning@w3c.org
I think I get it now... On Fri, 2004-04-09 at 16:19, Pat Hayes wrote: [...] > > HttpRange-14 is obviously relevant to this issue, but it doenst > resolve it. OK, suppose URIs can indeed denote real red cars and > imaginary white whales. That resolves httpRange14. Now, how does the > owner of a URI *say* that his URI shall be the name of *particular* > red car or white whale? > > BTW, it would be perfectly fine to say that there was no general way > to do this, and that you just have to do your best to describe the > things as well as you can. OK, I suppose we can agree to that. > At least then we would know where we stand. BUt then y'all ought to > take out all that mantra about resources being uniquely identified by > URIs. We have made some progress in that direction. I just scanned the document, and nowhere does it say "each URI denotes a unique resource"... at least not using the word "unique". I'll have to re-read your message to public-webarch-comments, where you excerpt lots of text that bothers you. I'm only aware of 1 at this point: We still have "A URI must be assigned to a resource in order for agents to be able to refer to the resource" which overstates the case since you can refer to things using owl:InverseFunctionalProperty expressions but without giving them URIs. > You can't have it both ways. If the Web is essentially a trade in > descriptions, then unique URI reference is achievable only by some > external technique of rigid designation, many URIs are not unique > identifiers, and most 'resources' are not uniquely designated or > identified. Which is fine and fits OWL/RDF. Yes, quite. > Or, if URIs really are required to be unique designators, ie names, > then there needs to be some principled way to baptize resources with > URIs. Which would be fine also. And it would be fine to have some > URIs one way and others the other way, as long as we could tell which > was which for most purposes (which I think is close to the actual > situation, in fact). But right now we seem to have a reality which is > descriptive, or a mixture, and a rhetoric which is insistently > nominal, and they don't fit together. Which is not fine. Hmm... I guess I think of the architecture as being ideally nominal, but practically descriptive. Some minor points... [...] > > > (Arguably, the connection between an http: URL and the thing you > > > GET when you use it with the right protocols could be said to be a > > > naming, and the Web itself is the baptising "authority". > > > > That appeals to me. In fact, does it really need saying at all? > > Isn't it obvious? > > > Well, OK, I thought it was also. But then a lot of the stuff in the > architecture document and rfc2396bis and even in the RDF semantics > doesnt really make sense, because all these things seem to assume that > the [URI--indicates/denotes-->resource] relationship has its net cast > much wider than this. So? If x > 10, it's not wrong to say that x > 5. > This only works for cases where the internet http: GET protocols do > the identifying. It doesnt get you to URIs denoting people or kinds of > wine or galaxies or books on a library shelf (Roy's example) or > imaginary white whales. But it doesn't conflict with those cases. > I meant that it isnt apparent from reading the document. > > This doesnt seem to me to be a very difficult issue. If the TAG are > painfully aware that they themselves disagree about what a word means, > then surely it should be obvious that they shouldn't use that word > without some warning or explanation of which of the various senses > they mean? Im not asking them to declare which sense if the right one, > just to resolve ambiguity. Well.. there is a warning... And there is a warning: "The TAG has selected a subset of issues that the First Edition does address to the satisfaction of the TAG" and "See the related TAG issue httpRange-14." Yes, it would be better to explain the various senses, I suppose. But that would require one person to understand and appreciate all of them enough to write them down to the satisfaction of all parties. That's... real work! [...] > > Haven't you been working in groups long enough to appreciate > > how difficult it can be to achive consensus on something like > > this? > > > I'm not asking for consensus. Im asking for clarity. You can be clear > about lack of consensus. > > What I think might be going on is that the TAG are trying to give the > appearance of consensus when they in fact do not have it, by trying to > hedge round the disagreement by using language in a deliberately > ambiguous or indeterminate way. It would be better to acknowledge the > lack of consensus openly, IMO. Almost the worst thing that a practices > document can do is to be ambiguous at a point where there is known to > be strong disagreement, and room for misinterpretation. Achieving > surface consensus on wording when there is no consensus on substance > resolves no real problems, but just means that both sides can claim > the document as authoritative on their side of the continuing debate. Quite. I just haven't figured out how to improve the situation. > But to speculate along these lines is rather unfair, since I havnt > given the TAG time to respond to my rather long rant to them yet, so I > will shut up at this point. I agree we've reached a point of diminishing returns. I'll study your earlier comments again, now that I think I understand some things better. > Pat -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ see you at the WWW2004 in NY 17-22 May?
Received on Friday, 9 April 2004 18:05:04 UTC