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

>On Thu, 2004-04-08 at 15:23, Pat Hayes wrote:
>>  >On Tue, 2004-04-06 at 20:53, Pat Hayes wrote:
>>  >[...]
>>  >>  But the direct answer to your question is that we don't really have a
>>  >>  way to do that, actually, yet. Not a fixed, standard way. And IMO,
>>  >>  until the TAG group gets its communal head out of the sand, or
>>  >>  whereever it has it located,  we never will, because the TAG group
>>  >>  thinks that URIs are already anchored to "resources" which they
>>  >>  uniquely "identify",
>>  >
>>  >I don't understand why you find this notion novel, let alone
>>  >disagreeable.
>>
>>  I don't. Its called naming, or identification. its a very useful and
>>  powerful idea. The problem is that the TAG group seems to think that
>>  it just kind of happens, or maybe is just kind of true, so doesn't
>>  need to happen, or something.
>
>Ah... so perhaps I parsed the head-in-the-sand comment as
>attached to the wrong bit... ok...
>
>>   Take the architecture doc draft: it
>>  just ASSUMES that it is meaningful to talk about the resource
>>  identified (named) by a URI, that URIs and resources have owners, and
>>  so on, all without explanation or even introduction.
>
>Well, we introduced URIs in a way that we thought was fairly typical
>of the way most people are introduced to them:
>
>[[
>While planning a trip to Mexico, Nadia reads "Oaxaca weather
>information: 'http://weather.example.com/oaxaca'" in a glossy travel
>magazine.
>]] -- http://www.w3.org/TR/webarch/#intro
>
>>   But nobody says
>>  anything about how all this structure of naming and ownership is
>>  actually handled: there are no protocols for naming things or for
>>  claiming ownership of URIs.
>
>The typical protocol is: you register a domain name and
>set up a web server and then announce it thru existing
>communications channels.
>
>We discuss that very briefly:
>
>[[
>The requirement for URIs to be unambiguous demands that different agents
>do not assign the same URI to different resources. URI scheme
>specifications assure this using a variety of techniques, including:
>
>Hierarchical delegation of authority. This approach, exemplified by the
>"http" and "mailto" schemes, allows the assignment of a part of URI
>space to one party, reassignment of a piece of that space to another,
>and so forth."
>]]
>  -- http://www.w3.org/TR/webarch/#uri-ownership
>
>Do you think it would help to elaborate on how the weather service
>registers its domain and such?

No, that isnt what I meant. We seem to be at cross purposes. 
Registering a domain name gets the 'source' onto the global network 
and allows it to create URIs.  Good,got that.  But now: what 
determines what it is that those URIs *denote* ?? More particularly, 
suppose that I own  weather.example.com and here I am with my 
webserver set up. I have a licence to create this URI: 
"http://weather.example.com/oaxaca" and I can arrange that my web 
server sends back something nice when it is pinged with it. OK, got 
that also.  But still, I havnt said what it is that this URI is 
supposed to denote (unless it denotes the thing on my Web  server? 
That seems to be what it represents in the REST sense).  How could I 
possibly say what it denotes? Suppose I want to have the URI 
"http://weather.example.com/weather-Inc" denote my company, or 
"http://weather.example.com/people/companyBoss" denote me. How can I 
do that? What way is there for attaching a denotation to a URI, of 
saying 'this URI, which I hereby invent, shall be the name of <insert 
named thing here>' ?

>  > In fact, naming is complicated, and in broader human society is
>>  surrounded by legally defined protocols and rituals and prohibitions.
>>  Like I said at the Boston plenary, there is no notion of baptism on
>>  the Web; and until we get one, there really aren't any names on the
>>  Web.
>
>Doesn't the section on uri ownership cover this, if somewhat
>briefly?

No.

>Are you using 'baptism' in some technical sense? or just the
>conventional sense of "A ceremony, trial, or experience by which one is
>initiated, purified, or given a name."

Right, in that sense, exactly.

>http://dictionary.reference.com/search?q=baptism&r=67
>
>>   (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. 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.

>  >  That makes
>>  sense for http: URLs, but isn't much help for RDF or OWL.)
>
>OK, now you've lost me. What difference does it make to RDF
>or OWL whether the names start with http: or ftp: or mailto:?
>If it works for http: URIs, why not the rest of them?

Because the way that 'it' works depends on the protocol, right? I'm 
not saying that OWL needs the http: prefix: I'm saying that the story 
about naming given above, that you liked, depends on it.

>Why not in RDF/OWL?

What internet transfer protocol gets you from

http://ontolingua.stanford.edu/doc/chimaera/ontologies/wines.daml#LOIRE

to a wine-growing region in France? Remember, what we said for the 
http: was that the GET protocol defined the name: but for examples 
like this, all that gets you is a string in a DAML document. How do 
you get from there to the intended DENOTATION ?

>
>>  >Names denote things.
>>
>>  Yes, but they don't JUST denote things. They denote things rigidly,
>>  in special ways. They NAME them, in the actual world, not just
>>  relative to an interpretation.  To claim that my name is "Bill
>  > Murray" is just plain flat wrong, even if you are willing to think
>>  about an interpretation in which "Bill Murray" denotes me.
>
>"just plain flat wrong"... now that's a new one.

My name isn't "Bill Murray", is all I meant to say.

>
>I'm familiar with the leves of truth discussed in
>logical literature such as
>
>   Three Levels of Truth
>   http://www.earlham.edu/~peters/courses/logsys/3levels.htm
>
>but I'm not familiar with that one.
>
>The only way I know to relate claims like saying your
>name is "Bill Murray" to ... er... actual reality
>is with economics and utilitarian measures. i.e.
>you haven't agreed to answer to the name "Bill Murray"
>so if I want to get your attention, calling out "hey Bill Murray!"
>is not likely to help me much. And if the police want
>to catch a criminal called "Bill Murray" they'll be
>wasting their time if the go to your house, and so on.

Well, you can go all Dewey-pragmatical on me, I guess, and then we'd 
have to chase all over the last 100 years of linguistic philosophy.

It seems to me that the idea of naming things is pretty basic and 
intuitively well-understood, and that the relationship of a name to 
the thing it names is clearly more than just one of denotation. If 
you read in a math proof "let S be a set ..." then "S" is a logical 
constant, but its clearly not a *name* in the same way that, say 
"Paris" is the name of a city in France. Names come with an 
expectation that they can be used to refer without further 
explanation, but logical constants don't. Logical constants (often 
called logical names, I concede: but then field theory isn't about 
growing grass) are really very similar to existentially quantified 
variables, in fact. Names - real names, 'proper' names - are more 
than just this.

>  >  Names
>>  play a special role in communication.  And in any case its not at all
>>  clear that what the TAG means by 'identify' really is denotation.
>
>No, it's not all that clear how it relates to Tarski and such.
>I hope we'll figure that out in the coming months/years.
>But I think the document isn't totally useless in its
>present state.

I agree its not useless. If you interpret it as being about URLs and 
networks then it makes almost perfect sense and is very useful.

>
>>  >It's a recurring pattern
>>  >in languages. For example, in SCL:
>>  >
>>  >
>>  >A nonempty set UI called the universe;
>>  >A mapping intI from VO to UI;
>>  >
>>  >-- http://www.ihmc.us/users/phayes/SCL_current_2004_rf.html
>>  >
>>
>>  Nothing there about naming.  SCL hasn't got any names in it (except
>>  maybe things like datatype URIs, arguably.)
>
>This use of 'name' is new to me.

Its just the ordinary English use.

>I had previously considered
>names to be just a kind of term, i.e. a syntactic device.

Well, they are, but they have a lot of linguistic baggage to carry.

>
>For example, you/we wrote:
>
>"for example, this semantics assumes that names denote things in a set
>IR called the 'universe'"
>   -- http://www.w3.org/TR/rdf-mt/
>
>But now you're saying, pretty emphatically, that there's some other
>notion of naming that you think webarch should discuss, yes?

Yes. Look, I was using 'name' there in a restricted logical sense (I 
prefer 'logical constant' for just that reason: formal logic really 
doesn't have any names in it.)  In that context, for example, there 
is no such action as 'naming'. But the notion of 'name' in society in 
general is a different, larger, notion. Kripke has argued for example 
that names denote their referents necessarily, ie that the 
name-->named mapping is 'rigid' denotation rather than just simple 
denotation. As Dan B noted, Grice had some other things to say about 
causality and naming.

I don't mean to get into all this deep stuff here or to argue for a 
philosophical position regarding the true nature of naming, but it 
seems clear that there is a notion here that needs to be respected, 
that is central to the Web (the use of 'assign' language and 
ownership talk is all tied up with it, for example) and is not fully 
captured by any kind of logical semantical analysis.

>
>>  >The webarch document is written in much less formal terms,
>>  >but it's the same idea.
>>
>>  No, its NOT. Its a different idea. Names refer, but all reference
>>  isn't done with names.
>>
>>  >The webarch document suggests
>>  >an idealization where there's just one interpretation,
>>  >but that's just an idealization.
>>
>>  That is not an idealization for GET applied to URLs.  There is a
>>  genuine notion of identification, and for URLs indeed it is an
>>  architectural requirement that URLs really do identify in this sense:
>>  its vital that the identification be unique in that case. URLs really
>>  are like Web names, but only for Web resources.
>
>'Web resource' is the universe of discourse, no? Ah... perhaps
>you mean resources that are on the Web in the sense of...
>
>[[
>Note: The Web Architecture does not require a formal definition of the
>commonly used phrase "on the Web." Informally, a resource is "on the
>Web" when it has a URI and an agent can use the URI to retrieve a
>representation of it using network protocols (given appropriate access
>privileges, network connectivity, etc.). See the related TAG issue
>httpRange-14.
>]]
>  -- http://www.w3.org/TR/2003/WD-webarch-20031209/#dereference-uri

Yes, but that language is systematically ambiguous (because 
'representation' might or might not connote reference, and there is 
no way to tell.) But given what I *think* this is intended to mean, 
yes.

>I think TimBL, the leading proponent of making that distinction
>in the webarch document, prefers the term 'Information resource'.

Right, that is what I meant. Things you can send information to and 
from over a network; things that react to network protocols.

>You seem to be arguing in the same direction. But I'm not sure
>I see an argument clearly enough to convince other TAG members.

I have to leave that problem to you, Im afraid. Ive given it my best 
shot. (I'm not sure what counts as an argument here. What case needs 
to be argued? That 'information resources' exist?? That is surely 
obvious. That some facts are true of network resources that are not 
true of other things? Again, surely obvious. That much of the 
language of the architecture document seems to apply only to network 
resources? That ought to be obvious, but I've sent you extended 
detailed comments pointing out examples.)

>  >  The TAG seems to be
>>  talking about that notion (or a Webbish version of it) most of the
>>  time, which is fine; but that's one idea, and reference is a
>>  different idea. The TAG seems to be confused about this distinction.
>
>Well, undecided, at least.
>
>>  >If you like, look
>>  >at a webarch:resource as a mapping from an SCL
>>  >interpretation I to an element of U[I].
>>
>>  Well, I tried that, but then 95% of what the architecture document
>>  says doesn't make any sense. For a start, if the entire architecture
>>  document is supposed to be relative to an interpretation, how does
>>  anything ever use the internet to communicate? You can't send an
>>  interpretation over the web.
>
>no, only representations.

Right, and if those representations must be interpreted, then....

>
>>  BTW, if this is right, then there *really* are no names on the Web,
>  > since even http: URLs aren't names if they denote only w.r.t an
>>  interpretation.
>
>I'm not sure how best to view it. Web architecture works
>best if they really are rigid, but it degrades fairly gracefully
>if, on rare occasion, a few of them are not.

Really? That is news to me, but interesting. And its encouraging to 
see you using a term like "rigid" here. :-)

Baptism is (for our purposes) the assignment of a rigid denotation to 
a name, how's that? I'd like there to be some statement of how to do 
that on the Web, or a best practice kind of discussion of how to 
approximate it, or whatever. Because until there is, language like 
"... assign a resource to a URI" is just fantasy. (Some URIs need 
rigid designators, some don't, BTW.)

>
>>  >Or look
>>  >at each protocol message as carrying its own interpretation
>>  >or something. It doesn't matter that much. The webarch
>>  >document doesn't constrain things that formally; it
>>  >uses more utilitarian/economic descriptions such as...
>>  >
>>  >
>>  >"a resource should be assigned a URI if a third party might reasonably
>>  >want to link to it, make or refute assertions about it, retrieve or
>>  >cache a representation of it, include all or part of it by reference
>>  >into another representation, annotate it, or perform other operations on
>>  >it".
>>  >  -- http://www.w3.org/TR/webarch/
>>
>>  That's NOT a more utilitarian way of talking about Tarski: it is
>>  something else altogether. It uses the words "assigned to" for
>>  example which has no meaning in a Tarskian semantics. (It also talks
>>  about linking and retrieving and performing operations on resources,
>>  which opens a whole other can of worms.)
>>
>>  This is exactly the point where John's question has some force: HOW
>>  does one assign a resource to a URI?
>
>Use the resource in communication protocols.

Suppose the resource is a human being or a company or an imaginary 
white whale. How does one USE those resources in communication 
protocols?

>
>>    What do you DO to get the
>>  assignment done?
>
>Most typically: register a domain name and set up a web server.

That doesnt assign anything to a URI.  Web servers emit symbols, is all.

>
>>   If you are inside a single interpretation, this
>>  makes no sense: the interpretation has already assigned a denotation
>>  to the URI. If you aren't inside a particular interpretation then
>>  presumably this would be done, classically, by restricting the set of
>>  interpretations by making suitable assertions, right? But how can you
>>  attach a unique referent to a name by making assertions (in OWL,
>>  say)? All you can do it to relate URI referents to other URI
>>  referents. You have to have some referring names to get the process
>>  started.
>>
>>  Analogy.
>>  OWL and its MT lets you draw maps. You can get the shapes right that
>>  way. What you can't do just by drawing maps is set up the coordinate
>>  system that a map uses to anchor itself to a position on the actual
>>  planet, the latitude and longitude.  That requires some conventions,
>>  some agreements about where exactly the origin is and how long a
>>  degree is and which way is north.  We don't have these conventions
>>  yet for reference on the Web. (Well, maybe URNs provide some, but
>>  they don't seem to get used very much.)
>>
>>  >  >  and so refuses to think about the fact that they
>  > >>  aren't, and what to do about it.
>>  >
>>  >Oh bull-pucky. There are megabytes of evidence to the
>>  >contrary. The TAG thinks about it a lot,
>>
>>  I havnt seen anything in any of the TAG archives that addresses the
>>  issue John was referring to, which is how to assign a name to a thing
>>  (not a resource, a THING.  Like a person or a company or a star.)  (I
>>  havnt read them ALL, however, I admit)
>
>[Again: 'resource' is the universe of discourse, so I'm not sure
>how to take "not a resource, a THING". Presuming you mean
>"not an information resource" or some such...]

Right. And there was an implicit request to try stating your answer 
in ordinary English instead of TAG-speak, since the whole problem Im 
complaining about is that TAG-speak hasnt got a well-defined coherent 
single meaning.

>I think we're agreed that, in general, one assign names to things via
>communication protocols.

in some sufficiently broad sense of protocol, OK. But there arent any 
of those on the Web, as far as I can see.

>But beyond that, lots of people disagree...
>
>One position on httpRange-14 is
>that to assign a URI to a person, you refer to that person
>using an expression in some language like RDF or OWL...

Begs the question. HOW do you refer to a (single) thing in the real 
world,  such as a person, in a language like RDF or OWL? That is 
where we came into the discussion, if you recall.

>
>   <foaf:Person rdf:ID="DanC"> ... </foaf:Person>
>
>and you use that RDF document as the representation of some
>information resource, say http://www.w3.org/People/Connolly/home-smart .
>Then the expression http://www.w3.org/People/Connolly/home-smart#DanC
>is an expression for "whatever DanC means in representations
>of http://www.w3.org/People/Connolly/home-smart".

OK, but that still may not be a name. For example, it may well have 
different denotations in different interpretations.

>But another position on that issue is that, for example,
>http://www.markbaker.ca/ is a name for Mark Baker because
>it's his URI and he says so.

HOW does he say so? On the Web, that is? That is exactly what Im 
asking for: a way to *say* that a URI names something.

>
>>  But If Im wrong Id be delighted to be told where to look.
>
>The discussion history of this issue is long:
>
>"Discussion history
>         1 Jul 2002, 15 Jul 2002, 22 Jul 2002, 29 Jul 2002, 16 Sep 2002,
>         24 Sep 2002, 6 Jan 2003, 27 Jan 2003, 6 Feb 2003, 23 Jun 2003,
>         22 Jul 2003, 28 Jul 2003"
>http://www.w3.org/2001/tag/issues.html#httpRange-14
>
>I remember a particularly intense discussion in Irvine, but I can't
>find a record of it. The record from Vancouver is pretty good...
>http://www.w3.org/2002/09/24-tag-summary#httpRange-14
>
>Ah... there's the Irvine record
>  http://www.w3.org/2003/02/06-tag-summary
>in particular, section
>  3.2 URIs, Resources, Identification (httpRange-14)
>

I hadn't seen the whiteboard pics, but I've read all those emails. 
There is nothing in any of this about the issue that we are talking 
about here.

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

>
>>   (And in
>>  that case I reckon that the architecture document ought to say
>>  something about this, BTW.)
>>
>>  >and TAG
>>  >members have thought about it and written about it
>>  >for at least 10 years, and I'm not aware of any
>>  >indication that it will stop.
>>
>>  All I keep hearing is that URIs 'identify' resources. Nobody EVER,
>>  EVER says what in hell's name a "resource" is supposed to be (why
>>  can't the TAG speak English like the rest of the planet?
>
>Perhaps because it's a 9-headed beast, not a single person?

Well, that would explain a lot, I agree.

>
>>   I know YOU
>>  have an answer, Dan, but your answer makes the architecture document
>>  incoherent) or what exactly they mean by "identify". As far as I can
>>  tell, what Roy means by "representation" in the REST model is
>>  something completely different to what everyone in KR or linguistics
>>  means. Which would be fine, if we could get the distinctions clear:
>>  but we don't have it clear, and the TAG group just uses the word
>>  without ever clarifying what sense of it they are using, and often
>>  with no apparent awareness that there are multiple meanings that need
>>  to be distinguished.
>
>We're very, very painfully aware.

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.

>I don't think actual blows
>have been exchanged, but very close to it. The issue was
>"postponed" for a while because we were unable to discuss
>it civilly.
>
>
>>  I have made several carefully worded requests for definitions or even
>>  just for clarification. So far the best response I've gotten is from
>>  Tim, who tells me that this is an "issue" that the TAG decided to
>>  postpone. Speaking clearly and saying what you mean is an "issue" ??
>
>Absolutely.

Oh, fiddlesticks. Make it a real issue then:

speakClearly-45.
Statement: when the group is unable to resolve internal disagreements 
about the proper meaning of some word, it should not use that word in 
any documents without giving some indication to the reader which 
sense is intended.

>  > Using words carefully and explaining what you mean by them in order
>>  to communicate properly is not an "issue": it's English composition
>>  101.
>
>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.

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.

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 Friday, 9 April 2004 17:19:19 UTC