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.

Great.  (Really !)

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

Maybe this could be (perhaps later in the document) modified or 
expanded to something like

"SW formalisms such as OWL provide ways to refer to resources 
indirectly by describing their properties. This extends the reach of 
the Web, by making it possible to refer to resources which do not 
have a URI assigned to them but are suitably related to resources 
identified by URIs."

maybe with a disclaimer about this being relatively new and not fully 
explored technology yet, or some such. That would both qualify the 
overstatement appropriately, and also acknowledge that 'descriptive' 
reference does ultimately depend on some kind of external anchoring 
and can't be done *just* by describing things.

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

Well, OK, but the trouble is that things like the TAG architecture 
document tend to rapidly get treated as Holy Writ, and so a careless 
phrase can have truly awful consequences once the Gods have gone back 
to Mt. Olympus and all we have left is the tablets of stone to argue 
over.

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

No, but it is kind of misleading to keep on about numbers fitting 
into two bytes when you seem to be talking about all numbers.

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

Lots of the stuff said in the LC architecture document does. Like for 
example talking about resources being connected to one another, or 
URIs providing ways to perform operations on resources.

I guess the problem is that all of this reads like its talking about 
resources generally, rather than about a particular kind of resource, 
since it is stated without qualification.

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

Ok, thanks.

Pat

>
>>  Pat
>
>--
>Dan Connolly, W3C http://www.w3.org/People/Connolly/
>see you at the WWW2004 in NY 17-22 May?


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Saturday, 10 April 2004 00:19:51 UTC