some notes

Sorry this all has a stream-of-consciousness air about it and rather 
jumps from topic to topic, I didnt have time to write something 
shorter before the telecon. There is a kind of theme to all this 
stuff, however.

Pat
------------

1. Let's stop talking about what the meaning of a URI is, or might 
be. I suggest that the question is underdetermined, and cannot be 
answered sensibly, since 'meaning' can only be said to apply to 
larger pieces of representation than single words or URIs. We are 
being misled by the analogy with NL.  English words seem to have 
meanings all by themselves, in isolation as it were, but in fact 
those meanings are determined by a huge amount of surrounding 
knowledge and presupposition and shared beliefs.  Dictionary 
definitions are not really definitions in any foundational sense: 
they are kind of sketches of a meaning which themselves rely on the 
same connected web of shared knowledge (some of it about language 
itself) which they set out to explain. URIs don't have this 
surrounding context of shared beliefs and so on; and in any case, 
URIs are not NL words.

In addition, it is notoriously hard to say what a 'meaning' really 
is, and there seems to be little point in this group diving 
head-first into a philosophical tar-pit as its first act.

2. One thing on which all parties seem to be agreed is that the Web 
and the SWeb both work fundamentally by passing around 
representations.  The RFC 2396 sense of 'representation' might not be 
exactly the KR-logic inspired sense that is used in talking about 
RDF/OWL stuff, but lets assume for the moment that they have enough 
in common that it is worth trying to put together a common story that 
covers them both.  (I want to start off by deliberately avoiding the 
question of what it is that these are representations OF.) As far as 
I can see, the story goes something like this (based in part on the 
REST model underlying RFC 2396, insofar as I can follow it. I am 
deliberately avoiding using the term 'resource', however, and I know 
that this is  vastly oversimplified and it ignores all kinds of 
architectural issues, eg a source can be a user also, etc.. )

a. The Web is comprised by a collection of 'sources' which are 
identified by URIs, linked by network protocols to a set of users.

b. A URI provides users access to a source and allows some operations 
to be performed on it; one such operation is poking it, ie requesting 
it to emit a representation.  The basic Web transaction consists of a 
user using a URI to send a poke to a source, which responds with a 
representation which is returned to the user. (REST has this being a 
set of representations, I think to accommodate MIME types, etc.(?); 
no doubt this would be required in a more thorough account, but let 
me ignore this for now.)

c. Representations represent, and may (typically will) contain URIs. 
URIs identify a unique source no matter where they appear in any 
representation: the 'identification' of the source - the 
URI-to-source mapping - is maintained by the (state of the) network 
itself.

Now, this account so far seems to work reasonable well both for HTML 
on the everyday Web and for RDF/OWL on the Sweb. There are 
differences, to be sure, but there is a common story in outline. The 
Sweb may not utilize the network identification process quite so 
thoroughly as the HTML Web does, and it uses URIs in ways that are 
not reflected in the Web architecture and have nothing very much to 
do with their role as identifiers, but these differences are not 
harmful, in that the two ways of using URIs can coexist without 
getting in one another's way and maybe can even be combined in a 
useful way, as in the convention that the root URI of a URI+fragID is 
a source which emits representations which supply information about 
the thing denoted by the URI.

3. Unfortunately, RFC 2396 has conflated two rather different 
relationships between a URI and a thing, viz. the 'identification' 
sense in which a URI provides access to a source on a network, as 
just outlined, and the 'denotes' or 'names' sense in which a URI is 
simply a name which denotes something in the, or even in a, world. 
This in itself would not be so bad, in fact, if we recognized that 
the first sense is a (very) special case of the second sense: after 
all, network sources are things in the world, presumably, and can be 
referred to.  But the RFC 2396 prose seems to be predicated on the 
assumption that these two relationships are *identical*, which is 
simply an error. It is a kind of colossal error, in fact, cosmic in 
its metaphysical scale and consequences; it imports a surreal fantasy 
into the very heart of the Web architectural theory.  Accepting it 
has led a number of smart people into making fantastical, nonsensical 
claims, such as that galaxies are 'on' the Web, or that the map is 
the territory, or that resources have no identity criteria, or that 
the act of typing a new a URI automagically brings a resource into 
existence.

This conflation is seen in the strange uses to which this artificial 
word "resource" has been put, where on the one hand, we are told that 
resources are on a network, are uniquely identified by URIs (in fact, 
that it is a necessary truth that all URIs must identify a unique 
resource) and that the URI provides access to the resource, allowing 
operations to be performed on it: and yet also, that a 'resource' can 
be anything at all, including imaginary or Platonic entities, 
galaxies far, far away and things that are too small to count or 
identify.  This simply does not make any sense: it doesn't make sense 
to claim to provide access to perform operations on Julius Caesar or 
the Whirlpool Galaxy.  What does make sense is that the first set of 
conditions are appropriate and reasonable for the 
URI-identifies-network-source notion, and the second claim makes 
sense for the URI-denotes-entity notion. The craziness arises from 
thinking these are the same and that the same 'resources' are 
involved in both cases.

I go over this stuff here (rather than the TAG group) because this 
regrettable confusion has permeated these discussions.  Since (it is 
claimed) a URI must identify a single resource - again, this does 
make sense in one reading, but we are now going to move to the other 
- that therefore all URIs must have a single *meaning*, and moreover 
that this single meaning must be fixed globally in all uses of the 
URI in all contexts.  This is bad enough: but this has taken even 
crazier form in the idea that this must mean that all URIs must have 
single denotation in all interpretations, a claim that is close to 
being incoherent, rather than merely wrong.

(This is something of an aside, but a close reading of RFC 2396 and 
the REST documentation makes me suspect that the use of 
"representation"  there differs fundamentally from the way this word 
is used in semantics and KR work. I *think* - I would welcome 
correction if this impression is mistaken - that when REST talks 
about a representation of a resource, it means the sense in which for 
example the HTML emitted from a website is a representation *of the 
state of part of the Web server* at that address, rather than a 
representation of whatever the text of that HTML is in some sense 
'about', eg astronomy, say, or liver disease. Similarly, if the web 
'source' at that URI is, say, a live webcam, then the representation 
is a representation *of the state of the camera's phtoreceptors*, and 
hence of whatever the camera is seeing. In other words, this usage of 
'representation' seems to be a relationship between a kind of 
snapshot of some network entity and the entity itself, or something 
physically attached to it rather closely, rather than a relationship 
between something like a text and whatever is described by the text. 
It is what has been called a grounded, 'direct', representation, 
fundamentally computational in nature; unlike a descriptive, semantic 
representation. If this is close to correct, it might go some way to 
explaining the terminological disconnects which seem to arise in 
these discussions, since these two notions of representation are 
obviously orthogonal.)

So, the moral of this is, I claim, twofold: first, that we absolutely 
must keep these two distinct ideas clear in our discussions - that 
is, the network-maintained relationship between a URI and the 
information source that it identifies, on the one hand, and the 
semantic 'naming' relationship between a URI and whatever it might be 
taken to denote, on the other. Intuitions which are appropriate to 
one sense are quite inappropriate to the other.  Second, these two 
senses are, prima facia, quite independent: there is no particular 
necessary reason why a URI might not serve in both roles 
independently. So when talking about 'meanings', we need to be 
explicit about any relationships we might be presuming, or wanting to 
insist on, between these two senses.

BTW, URN's are obviously names. They also obviously do not satisfy 
the RFC 2396 prose: they do not, for example, provide access to the 
things they name or allow operations to be performed on them. 
(Wanting to subsume URNs and URLs under a common framework may have 
been the source of this truly disastrous confusion, BTW.) They are 
however a special case in that they seem to provide a uniquely 
Webbish kind of naming authority. I will return to this point later.

3. Although URIs are not NL words, they do seem to have some things 
in common with words, at least in the Sweb. They are both used to 
refer to things, in some suitably broad sense of 'thing', and they 
are the atomic syntactic units in a more complex language which makes 
assertions.  So I will pursue this analogy.

There seems to be a clear sense in which words get their meanings by 
virtue of being used by human speakers to convey information to one 
another, and that the information is encoded in those words, in a 
kind of mutual recursion.  There is a kind of web - if I may re-use 
that word for a second - of mutual belief and shared assumptions 
about the information conveyed by a word when used in various 
contexts which enables them words to convey meaning reliably. This 
has been analyzed to death, of course, and it can be summarized by 
saying that the meaning of words is determined by their 'social use'.

Now, this story can be extended to the SW, as follows.  The way that 
Sweb markup is supposed to be used is to enable software agents to do 
something useful with it; software agents which are supposed to be 
acting so as help satisfy the goals and intentions of human agents. 
We know what kind of thing these agents will be doing: drawing valid 
inferences, where 'valid' is as defined by the formal model theory. 
However, what the SWeb software agents are doing is only part of the 
story, since there will be other pieces of software and ultimately 
human beings also involved.  Seen thus, the Sweb will be an extension 
of human society, not something operating autonomously in isolation 
from human society. It is a 'society' in which software agents play a 
kind of social role, but a rather auxiliary one, since they are - I 
have to say this - as dumb as dirt, and cannot be expected to be 
aware of all the meaning carried by the formal notations they are 
processing. So, even though the software agents may be unaware of it, 
the formal notations they are manipulating may carry more meaning 
than is reflected by the model theory alone: in the precise sense 
that the conclusions of a SW inference engine may be used to sanction 
actions which are not, and could not possibly be, sanctioned *purely* 
on the basis of the specification of formal entailment. These are the 
actions taken by other software, and possibly by human beings, on the 
basis of the 'meaning' they are able to extract from the formalism 
*together with the background assumptions shared in the appropriate 
society of agents*.  As a simple example, suppose a SW services 
application, when processing an order for a piece of furniture,  uses 
some SW markup to infer that the customer is in a class called 
equifax:CreditHighLimit, and as a result allows the order to be 
shipped before the check is cleared. The SW reasoner knows, let us 
suppose, nothing about orders or shipping dates; nevertheless, it is 
able to make useful valid inferences which convey such information to 
other agents. The software which processes the entire transaction is 
able to interpret that class name in particular ways to sanction 
certain kinds of action, but it probably knows nothing about the 
general theory of credit liability or commercial risk; but someone in 
the organization probably does, and may bring that knowledge to bear 
when examining the very same transaction.  In general, the amount of 
'meaning' encoded in an expression varies with the community of users 
who are using it to convey or detect that meaning.  The Sweb does not 
depend on having software which can access or be sensitive to all 
these shades of meanings; but on the other hand, it should not a 
priori refuse to allow any kind of meaning to be encoded in its 
formalism by some community of users who may wish to take advantage 
of SW technology for some purpose, or to deny any kind of use of its 
formalisms to encode meanings, except of course when that would cause 
conforming SW engines to distort that meaning unacceptably.

4.  A basic idea in semiotics is that of the communication act, 
typically some kind of conveying of information from one agent to 
another. The best Web analogy to this seems to be the 
[you-ping-me-using-my-URI-I-send-you-a-representation] transaction 
sketched earlier. The Sweb extends this by also sanctioning the 
drawing of conclusions.  On this analogy, then, Sweb traffic is kind 
of like an ongoing chat room conversation where network sources and 
users are kind of talking to one another, drawing conclusions, maybe 
asking one another questions (queries) , and so on.  I think a lot of 
our discussions have this kind of picture acting as an 
intuition-pump: I know I tend to talk about Web pages as though they 
are 'saying' something , in any case.  But I wonder if this analogy 
really makes sense, or may be very misleading. After all, even if we 
allow software agents to be really agents, web pages don't actually 
*do* anything, and even Web sources don't do a hell of a lot.  Maybe 
we should be using a different metaphor, where the SW markup isn't 
being asserted by the source that delivers it, but is just kind of 
*there*, like writing in a book. This would separate apart the ideas 
of what its content is, on the one hand, and what an agent might be 
doing with it, on the other. Now we can put those back together in 
the form of a kind of architectural hypothesis or guideline, along 
the lines that the delivery of some SW content by a network source is 
presumed to be an assertion of it by some agent associated somehow 
with that source. At this point I have to give up the discussion to 
others: what agent, and associated how? (What kinds of such 
association are there? Are any of them mediated by software or 
network architecture, or is this association purely social?)

One point of this 'communication act' analogy is that it suggests 
that there might be quite a variety of such acts on the Sweb, by a 
variety of agents, with different kinds of association to Sweb 
content. For example, a service agent which sends an order to another 
service agent which processes the order might provide a special kind 
of Sweb communication act which has its own rules and protocols; but 
other kinds of act might satisfy different ones. The only thing we 
have said as a community about all this is that whatever they do, it 
ought to involve valid conclusions; and even that is controversial. 
If the analogy between SW and NL has any force at all, then it ought 
to be the case that 'meaning' will emerge from the conventions 
adopted in this variety of communication acts between real agents - 
agents that do things - using the Sweb markup.


5. What this 'chat room' analogy certainly suggests is that we cannot 
expect that all published Web content will agree. There will be 
inconsistencies between information available from different sources: 
ontologies will be mutually inconsistent. (I have always taken this 
to be simply obvious, but it seems to be a new idea to some people.) 
Im not sure what follows from this about 'meanings', but it certainly 
suggests that we need some ways to make Web reasoners more robust.

Another idea it suggests is that any agent which puts together 
information from a variety of sources and draws conclusions from them 
in combination (which could not be inferred from one of them alone) 
must be understood to be taking upon itself the responsibility for 
its conclusions.  The act of combination itself is taking a kind of 
risk, after all; and what else can be understood to be responsible 
for the conclusions? This is a new idea to me, by the way: that the 
performance of valid inferences can itself be considered to be taking 
a stance, and the conclusions may be at risk even if the sources are 
trusted and the inferences are valid.  (You may be correct in 
trusting both sources, but they may be relying on different 
assumptions. Neither of them may be willing to sanction the 
conclusions you are drawing.)

6. Following on the debate about URIs having a unique meaning, in 
discussions with Tim (and others, notably Patrick Stickler) I think 
Tim and I kind of agreed on the following. Observe that people 
communicate successfully when they use words with a shared meaning, 
and often fail to communicate when one has a meaning in mind 
different from that understood by the other, particularly when the 
word is a simple name and they don't have the same referent in mind. 
Summarize this by saying that successful communication depends on 
having a common shared meaning for the word. Now, following the 
analogy of a Sweb transaction as something like a conversational act, 
say that the successful use of a URI in a Sweb communication relies 
on - presumes - that the two agents have a shared common 'meaning' 
for the URI.

OK so far.

At this point I observe that *as far as the Sweb agents are 
concerned* this assumption cashes out to be simply the common use of 
the URI in the communication, and doesn't require any other 
presumptions or stipulations. If you send me some OWL and I send you 
some OWL and we both use it to draw some valid conclusions, so we 
both agree on the presumptions being used and both use valid 
inference techniques, then any model of your beliefs is also a model 
of my beliefs and vice versa: so we agree. If all we can do is to 
draw conclusions, then it is *logically impossible* for us to agree 
any more thoroughly that this.  In particular, it isn't necessary to 
stipulate that the URIs involved must have a single fixed denotation 
or referent, or that one of us (or something else) has the final call 
in determining the unique resource indicated by the URI, or any of 
that stuff. The model theory does enough by itself to ensure a common 
'meaning' allowing us to usefully communicate.

On the other hand, this nice picture makes several assumptions. 
First, that we are using the same sources. If you are drawing valid 
inferences from one ontology using the URI and I am drawing them from 
another, we may come to divergent conclusions.  Second, that we are 
only discussing here the meaning accessible to the dumb-as-dirt Sweb 
inference agents, the things that draw conclusions and do nothing 
else. If the community involved is understood to include other 
agents, who might be bringing other background assumptions to bear on 
the matter and which can take other kinds of actions - as it usually 
will, in practice -  then the use of an URI to convey meaning must be 
dependent on that background being consistent between the agents 
involved. If not, miscommunication may occur.  And these shared 
presumptions may go beyond what is stipulated in the OWL model 
theory, of course: in fact, they must, otherwise we would all be 
dumb-as-dirt inference machines after all.

(One might argue that this is the same point, in fact: whether the 
information involved is encoded explicitly in a formal ontology, or 
implicitly in a community of use, agents which bring different 
information to bear on a communication will be able to draw different 
conclusions from the subject of the communication. )

It may be that Tim's basic point in this debate was that we need to 
stipulate that for *any* community of agents, no matter how 
extensive, the 'meaning' of a URI must be taken to be uniquely fixed 
in any Sweb transaction. I would sharply disagree with this claim, if 
it is being made. This isn't true in human NL communication, even.  I 
don't think it makes sense on any dimension; the very idea of URI's 
having unique meanings is I think another silly consequence of this 
terrible confusion of an identifier identifying a source with a name 
denoting a thing.

-------

More later, hopefully more organized than this has been.

Pat

-- 
---------------------------------------------------------------------
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, 25 September 2003 23:22:51 UTC