W3C home > Mailing lists > Public > public-sw-meaning@w3.org > November 2003

Re: Meaning and context

From: pat hayes <phayes@ihmc.us>
Date: Wed, 5 Nov 2003 18:18:57 -0600
Message-Id: <p06001f5ebbcf397b9e13@[]>
To: Larry Masinter <LMM@acm.org>
Cc: public-sw-meaning@w3.org

>  >From the last teleconference, I was asked to write up my point
>of view.

Thanks, and the following is intended in a spirit of 
getting-things-clear-by-debate rather than as hostile.

>Meaning of terms comes not only from the terms but the
>context of use.

Exactly. Though that word 'context' often comes with some unfortunate 
baggage (which I don't think you intend here.)

>While it would be preferable to have only
>a single meaning for a "URI" in all contexts, there are
>already sufficiently different contexts that it is impossible
>to define a single semantics for a URI without doing damage
>to one or another set of existing specifications from W3C
>or IETF.
>So, I propose that the community as a whole (W3C, IETF, etc.)
>adopt a context-dependent semantics.

If I follow you correctly, I think this is rather like saying that we 
should adopt arithmetic in order to do our sums.  Semantics just IS 
context-dependent in this sense: we don't need to adopt anything, we 
just need to wake up and smell the coffee.  That is what Ive been 
yelling about.  (Not that Im exactly *disagreeing* here, you 

>I believe that W3C
>specifications currently have different contexts of
>use for URIs which have different enough semantics to be
>called out:
>(a) "As a hyperlink"
>   This is the context used by <a href="URI"> and
>   <img src="URI"> and so on. The URI is being used as an
>   active link following the computational or operational
>   semantics defined by the (definition of the) scheme
>   of the URI used.


>That is, the only thing a "http"
>   URI can "denote" is the operational definition:

Why?? You have just said that this is the *operational* meaning. I 
agree. But that doesn't restrict the *denotation* at all. It could go 
on having that operational meaning and denote anything we liked it 
to.  Consider it practically: suppose its embedded in some OWL and an 
OWL reasoner draws some conclusions, but never invokes the http 
protocols using it. So what? Nothing is thereby damaged and no harm 
is caused to anything. Conversely, suppose someone pings the URI and 
http fetches some html for you: the OWL reasoning doesn't give a damn 
about that and may not even know it has happened.

Obviously it would be handy if we could have some kind of 
relationship between the two, but it isn't *necessary*. And we have 
some freedom in deciding how best to do it, if we want to try.

>  it
>   denotes the result of the action of using the HTTP
>   protocol to the given host using the given path
>   in the protocol.

Well, we could say that, I guess, but Im not sure that is the best 
thing to say in all cases. We all need to discuss this in more 
detail, preferably with a good range of examples of what those 
'results' might be. (And, I thought that the proposal on the table 
was that the bare URI would denote the actual REST-resource, the 
thing at the end of the path, not whatever that resource emitted when 
you http-poke it. )

>(b) "As a concept identifier"
>   This context adds an implicit "thing described by"
>   level of indirection. URIs are used to denote the
>   thing that is _described by_ the resource that
>   is referenced by the URI used 'as a hyperlink'.
>   This is similar to what was intended by using "tdb"
>   in http://larry.masinter.net/duri.html.

My problem with this is that it begs a central question: when does a 
description identify something? Most descriptions (formal or in 
English) don't identify single referents uniquely, and it has been 
notoriously hard to state conditions on the form of the descriptions 
which can guarantee that they do. So I worry that unless this is more 
fleshed out, it will be meaningless while seeming meaningful, which 
is a dangerous combination.

>(c) "As an RDF concept identifier"
>   RDF seems to have bifurcated (a) and (b) by use of
>   the "#" fragment separator. URIs without fragment
>   identifiers are used to identify the hyperlinked
>   resource, while those with fragment identifiers are
>   used to identify the 'concept' that is described
>   by the resource.

Well, not exactly. There's no assumption that the URI#s are doing any 
'identifying'. They denote something, and whatever they denote, it 
had better satisfy the RDF/OWL assertions made using it. But that's 
about all you can decently say, and all you really need to say, as 
far as RDF/OWL is concerned.

>  http://www.w3.org/ denotes meaning
>   (a), while http://www.w3.org/# refers to meaning
>   (b), the organization.
>Concept identifiers (b) are used, in their own right,
>within ontologies, where communities of use agree
>to use _the same_ URI within the community, by establishing
>web resources (or imagining that one might establish
>a web resource) and then using its URI to refer to
>the concept.

I really don't think this is how it works. The ontology machinery 
does not in any way depend on URIs having unique referents.  Hardly 
any of them do, in fact.  Like, for example, NONE of the RDF, RDFS or 
OWL reserved terms have unique referents (except possibly 
owl:imports, at any given instant).

>For example, the context of "XML namespace name"
>that appears inside xmlns="URI" within XML is
>as a particular kind of concept (a 'namespace').

And that is *uniquely* defined, in *every* possible interpretation? 
Are you sure? How was that done?

>Note that the above theories of meaning (a)-(c) do
>not depend in any particular way on 'owners' or
>'authorities' establishing meaning; the reader or
>receiver of a communication that contains a URI doesn't
>need to know who the authority is or what they might
>have said at some time in the past in order to be
>able to interpret the URI.
>Context (b) (and by derivation, context (c)) do
>have communities of practice around them, but they
>are not necessary in order to create meaning.

Well, take your example: doesn't that idea of a 'namespace' reside 
ultimately in usage among a community? I don't think there is a 
machine-readable definition anywhere, or even what it could possibly 
look like. Ive never even seen a tight English definition.

>It is necessary to at least have (a) and (b) if
>you want to use 'http:' URIs in some contexts to
>refer to abstract concepts, because there is no
>way to ever shake off meaning (a). If you want a
>'http:' URI to be able to talk about your car,
>then you still need some way of talking about the
>resource of "what you connect to via HTTP" that
>is different from "your car". It is inescapable.

You are here *assuming* that there can only be one meaning, though. 
But different protocols can use the same URI differently. There's no 
doubt about what you get when you give an http: URI to http.  But 
calling that 'the meaning' kind of begs the central question, since 
it sort of presupposes that there has to be a single 'the' meaning. 
But that's the point: maybe there doesn't. Then this whole issue just 
turns out to be a boojum.

>There's no way to do the 'lifting' without a
>'lift' operator.
>http://larry.masinter.net  <- my web page, not me.

Hey, that's OK, I can deal with that much overloading. In fact I can 
write code that can deal with that much overloading, and I bet you 
can too.


PS. modulo all the above carping over words, I think that we are kind 
of in general agreement on the essentials.  Encouraging.

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 Wednesday, 5 November 2003 19:18:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:01 UTC