Very well then, I believe I am beginning to understand what the name of this
song is called, but there are still a few loose ends I'd like to tie up. (01)
on Sun. Jan. 6, 2008 at 1:24 PM, Pat Hayes wrote: (02)
> >I've read some of the references...I'm happy to concede that 'context'
> >may be better replaced by several more specific terms, or at least that
> >we always make clear that there are many *kinds* of context. And I'll
> >keep reading...
>>But I'd like to return to one part of this discussion with an example
>>'from the field' rather than my own manufacture. I'd like to get opinions
>>about this example as it still troubles me.
>>on Sat. Dec. 29, 2007 at 1:04 PM, Pat Hayes wrote:
>>PH>>>The key point is, what would count as a
>>>>>'context' for a context-dependent URI?
>>In the following example, the differing 'contexts' are the different
>>web-pages upon which occurrences of a URI appear.
>>>>>this scenario. You, sitting at your computer, use a URi to browse an
>>>>>interesting website, and you send me an email telling me about it and
>>>>>citing the URI. I then, sitting at my computer, two days later on the
>>>>>other side of the planet, type that URI into my browser. We expect that
>>>>>we will see the same website: but what do our two contexts have in
>>>>>common? It might be almost nothing: the times, places, browsers,
>>>>>countries, users, OSs, maybe even cultural and linguistic settings, can
>>>>>be completely different. It is inherent to the Web that the contexts of
>>>>>publication and of use of a URI can be arbitrarily different and far
>>>>>apart on every dimension, yet the URI is supposed to retain its
>>This scenario is not applicable here. We need the following scenario. You,
>>sitting at your computer, use URI-A to browse to an interesting web-page
>>upon which you see a small graphic, retrieved by an occurrence of URI-CD,
>>which refers to an assertion that the web-page you are viewing is written
>>in valid XHTML 1.0.
>>This is URI-CD: http://www.w3.org/Icons/valid-xhtml10
>>What this URI is intended to denote is this assertion (from the W3C help
>>page: http://validator.w3.org/docs/help.html) "To show readers that one
>>has taken some care to create an interoperable Web page, a "W3C valid"
>>badge may be displayed (here, the "valid XHTML 1.0" badge) on any page
> OK, very nice example. But lets be very clear about what exactly is
> denoting what. The badge is a graphic, which is emitted by (and hence
> webarch:represents) a Web object (belonging to the W3C) which itself is
> denoted by the URI-CD (because, following the httpRange-14 decision, no
> 303-redirection was done when you GET that URI). The badge is not itself a
> URI. Moreover, while it is being the object of the URI or URTIs which
> denote it, it isnt (yet) being used symbolically: it is simply an
> information object, a PNG file. But when used *as a badge*, ie as part of
> a visible Web page, then (let us agree) it does become a symbol, one
> which, as you correctly point out, is used indexically, since its
> occurrence on a Web page makes an assertion about that very page. But it
> still isn't a URI; so all that follows is that Web pages may contain
> indexical (human-readable) content, which is of course true. A web page
> containing an article which says "this article" contains indexical content
> also. Human languages and communication systems are rife with
> indexicality. (03)
I'm curious, first, about how you have handled *what it is* that the URI-CD
denotes. You say that URI-CD denotes the "web object" that emits and is
represented by the "badge". But we know more about it than that. Why call it
a "web object", or an "information object", or a "PNG file", or a "badge"
when we know precisely what kind of "web object" it is? We know that the
"badge" has "W3C XHTML 1.0 check" on it. We know why those symbols represent
the "web object". What we know, in fact, is that URI-CD denotes a "web
object" that can be represented by that "badge" because it can be symbolized
by the symbols on that "badge". And we know who created it, why they created
it, and what they intended it to be used for. All of this is surely what the
"web object" *is*, and is therefore what URI-CD denotes. Right? So why not
call a spade a spade and say that URI-CD denotes an assertion that the page
its emissions are shown on has valid XHTML? To say that the "web object" is
JUST a "web object" or "information resource", while ignoring the symbolic
content it contains, leaves out the essential characteristics of what is
denoted by that URI. After all, a "web object" that is Moby Dick is not the
same as one that is Alice in Wonderland - exactly because of the different
symbolic human content they contain. (04)
Second, you say that the badge does "become a symbol", with indexicality,
only when it appears on a visible web page. Why is this so? When does this
symbolic content emerge out of an "information resource" if it was not
already there to begin with? (05)
> But look what happens if you try to make that assertion (about being a W3C
> valid webpage) machine-readable. Lets assume that there is a category - a
> class - of W3C-valid web pages, denoted by a URIreference
> http://www.w3.org/IconClasses/valid-xhtml10 so that what we need to say is
> that this web page is in that class, in RDF
> <this web page> rdf:type http://www.w3.org/IconClasses/valid-xhtml10 .
> Well, we need a URI for this web page. In your example, it was URI-A,
> right? So the RDF is
> URI-A rdf:type http://www.w3.org/IconClasses/valid-xhtml10 .
> and we are done. BUt now there is no indexicality, and for a very good
> reason: this assertion can be anywhere. Even if it is stored initially on
> the web page at URI-A, that is no guarantee that it will stay there and
> only there. It is intended for publication and transmission on the Web,
> and it should *retain* its meaning when that happens. There would be
> (literally) no point in having an assertion on a Webpage which could not
> be used elsewhere, as it would be effectively invisible.
> There is another point. Even if we were to allow indexicality, that is a
> much more tractable business than arbitrary contextuality. Indexicality is
> pretty well understood, and takes only a smallish tweak on a standard
> model theory to handle it: basically, you have to treat the semantics as
> attached to the occurrence of the symbol rather than the symbol itself
> (or, equivalently, you treat the actual symbol, in the case of an
> indexical term, as being the pairing of the indexical with the appropriate
> part or aspect of the context of use: and indexicals indicate which part
> is relevant, so "here" refers to space and "now" to time, etc..) So, as
> usual, it isnt helpful to jump to an extremely general and
> poorly-understood term ('context') when a more precise and narrow one, on
> which a lot of work has already been done, is available.
>>Now you go to URI-B and see that same graphic, because the author of that
>>web-page put an occurrence of URI-CD on his page as well. But this
>>occurrence of URI-CD is used by the author of URI-B, to refer to his
>>(author of URI-B) claim that URI-B (rather than URI-A) is an
>>"interoperable Web page".
>>My claim is that the referent of each occurrence of this URI
>>http://www.w3.org/lcons/valid-xhtml10 is context-dependent upon the
>>web-page upon which it appears.
> No. That URI, wherever it appears, always denotes the Web object that
> emits the graphic. The graphic itself, when used symbolically as a
> 'badge', is indexical. But there are no indexical URIs anywhere in this
>>In other words it is essentially indexical: it always
>>refers to an assertion that "THIS page validates", where *this* changes
>>with each occurrence.
>>Now the strongest objection to this I can see so far is this: The URI
>>denotes a single unique assertion
> Nope. It definitely denotes the Web object which resides on a W3C server
>>as an uninterpreted whole, a black box, so to speak. Any further
>>interpretation of that opaque sentence, as an assertion of validity, for
>>example, is out of the scope of web-arch entirely. The indexical,
>>specifically, is only encountered later, by the client or her application.
>>Therefore, the URI denotes the same thing everywhere.
> Something like that, yes.
>>I'm still thinking about this...
>>[big snip about fingerprints]
>>PH> No, I think fingerprints don't have referents at
>>>all. Unless someone invents a 'language of fingerprints', but I haven't
>>>seen such a thing ever proposed.
>>I think this is a bit unfair since you used your rutabaga-reference
>>example. Does this imply a 'language of rutabagas'? :-) but no matter.
> The difference is that the rutabaga is the referent, the thing Im
> referring to, not the symbol which does the referring. In the example I
> refer to it by a gesture, rather than verbally. We subtle humans can refer
> in all kinds of ways, eg by a glance or a small nod of the head or even a
> raised eyebrow.
>>PH from another post>>"I can refer to a thing without naming it. We do
>>this all the
>>>>time. For example, I might pick up a vegetable in a supermarket and say
>>>>you, "Rutabaga?", using the vegetable itself as the object of my query."
>>JB>>So it is with a name (in
>>>>context) or a URI: The time-varying set of representations of the
>>>>doesn't change, but *what it is* may vary.
>>PH> But that is exactly what CL denies about names
>>>(and the TAG about URIs). Under appropriate http-200 circumstances, a URI
>>>denotes what it accesses. Which is unique, right?
>>I'm claiming that http://www.w3.org/lcons/valid-xhtml10 uniquely accesses
>>a small .gif file, but that it denotes an assertion about the the web-page
>>upon which each occurrence of the URI is embedded. Furthermore, I say the
>>W3C clearly stipulates that it denotes that assertion and not the .gif, in
>>spite of REST and TAG, that it has been used successfully to denote it for
>>years, without breaking the web, and that its denotation is just as usable
>>by machine-processors as by humans, since it may form the basis of a
>>parser choice, for example.
> No, I think you have this wrong. The URI denotes the source of the image
> files, and that (occurrence of the) image then, when appropriately used,
> can denote the page it is residing on and say something about it. But it
> only says this when it is on that page, i.e. implicitly: to make this into
> an explicit publishable assertion (using RDF or OWL or indeed any other
> ontology language) , you need to use a NAME for the web page in question:
> and as soon as you put that name into the assertion, it is no longer
>>Now are you saying that the CL specification, along with the TAG,
>>specifies that names must not refer to such indexical assertions?
> In CL you can't refer to assertions at all, so the question is moot.
>>>And under the REST model, a resource (in current jargon: information
>>>resource) *is* a function from times to webarch:representations. So *what
>>>it is* cannot vary, by definition, as a basic Web-architecture
>>>One reaction to this is to denigrate the lack of context-sensitivity in
>>>current Web communications.
>>My objection is subtly different, my objection is that a science of the
>>web may show that there are already some kinds of context-sensitivity in
>>current Web communications and it is not breaking anything. And this is
>>because some kinds of context are not hard to handle.
> Well, you might put it better (IMO) by saying that (some) indexicals are
> not hard to handle. But the key point, why this is not a counterexample to
> what I said below, is that it is not about indexical *names* - URIs - but
> about indexicality in 'badges', which I will concede is a real phenomenon.
>>For example, a browser knows what web-page it has got, and thus has an
>>easy time resolving the indexical.
>>>But another is to simply accept that the open, global nature of the Web
>>>makes it essential to presume that Web names - URIreferences - are
>>>transparent (every occurrence of them have the same meaning) and to write
>>>ontologies accordingly. The cost of the former - a complete re-design of
>>>the entire apparatus of Web logic along lines that are yet to be
>>>researched - seems to greatly exceed that of the latter, which really
>>>amounts simply to following a certain discipline in inventing URI
>>>references. At any rate, like it or not, this is how the SWeb is
> IHMC (850)434 8903 or (650)494 3973 home
> 40 South Alcaniz St. (850)202 4416 office
> Pensacola (850)202 4440 fax
> FL 32502 (850)291 0667 cell
> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (08)