Re: How does RDF/OWL formalism relate to meanings?

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