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

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

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. (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 makes 
sense for http: URLs, but isn't much help for RDF or OWL.)

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

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

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

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

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.

>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?  What do you DO to get the 
assignment done? 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)

But If Im wrong Id be delighted to be told where to look.  (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? 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.

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

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 Thursday, 8 April 2004 16:23:53 UTC