- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 9 Jul 2007 14:57:47 -0500
- To: Stuart Williams <skw@hp.com>
- Cc: Rhys Lewis <rhys@volantis.com>, noah_mendelsohn@us.ibm.com, Dan Brickley <danbri@danbri.org>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Tim Berners-Lee <timbl@w3.org>, www-tag@w3.org
>Hello Pat,
>
>With some trepidation I'll put my foot into this :-)
>
>Reflecting on what I've written below... I think the core question
>that I have for you, Pat, is about 'bootstrapping'. How do you find
>out something about something armed only with a reference to it? In
>part, your response to Rhys about the lack of utility of the
>attempted direct reference is base on having prior knowledge of its
>futility. My question is how did 'you' come by that prior knowledge?
Fair question. There are many ways, but they all boil down to being
told something about the thing in question. They all involve the use
of language, which uses names to refer: formal or informal language
doesn't really matter much at this point of the discussion, though
programs tend to do best with formal stuff :-)
But in the context of the discussion so far, I note that this point
was implicitly conceded by you and Noah, when you referred to the
'thing referred to'. That presumes one knows what is being referred
to. If all you have is a name, then there may not even be anything it
refers to, for all you know. So I was presuming that you knew enough
to know that the thing being referred to was, say, a galaxy.
>And... in absense of any knowledge, only a referring name what do
>you do if you want to know more about the referent?
In the absence of knowledge, there is nothing you can do to know more
about the referent (except ask, i.e. gather knowledge). Its not even
clear that it makes much sense to speak of reference without some
knowledge. Here's a name (a definite noun phrase) which I happen to
know refers to something when used by members of my family: "the shop
that doesn't sell axes". There is no way, without sharing some of
that knowledge, that you or anyone else could possibly determine what
the referent is.
>By all means read the rest of what I've written below... but i think
>that the questions above are the kernel of it.
>
>
>Pat Hayes wrote:
>>>
>>>Hello Pat,
>>>
>>>I'd like to ask my first dumb questions, if I may.
>>
>>Im sure they won't be dumb.
>>
>>>They concern your
>>>recent response to Noah's comments.
>>>
>>>Noah wrote:
>>>"Here's what I think may be the essence of the confusion: there are
>>>certain systems in which it is by definition possible to attempt to
>>>access anything that can be referenced."
>>>
>>>You responded:
>>>"Indeed this may well be part of the confusion. OK, there are a few such
>>>systems (a VERY few), but the Web is not one of them; or at least, not if
>>>its understood as described in the Web Architecture document. That
>>>document is at pains to explain, quite early, that resources identified by
>>>URIs can be physical things not connected in any way to the Internet, such
>>>as books and people. From that point on, all talk about attempting to
>>>access things that can be referenced is obviously crazy. You can't use
>>>HTTP or any other xxTP to access people and books. (You can maybe access
>>>some kind of description of them, which could be called a representation
>>>of them, although not in the same sense of "representation" used by you
>>>and the architecture document; and not by getting a TP poke to them and
>>>causing them to emit a representation in response. But you didn't say
>>>'representation': you said, access anyTHING that can be referenced.)"
>>>
>>>My question concerns whether I've interpreted your response correctly. I
>>>was somewhat surprised by your apparent assertion that the Web is not a
>>>system which Noah characterised as one 'in which by definition it is
>>>possible to ATTEMPT (my emphasis) to access anything that can be
>>>referenced'.
>>
>>Before reading on, let me emphasize that I am taking Noah's words
>>here at their face value. That is, the situation as he describes it
>>is one where (1) there is a URI (2) it is known that this URI is
>>intended to reference, say, a person or a book (a "non-information
>>resource"), and (3) it makes sense to attempt to access this person
>>or book ("the thing referenced"). But I know, without further ado,
>>that it does not make sense even to attempt to access a person or
>>book (or galaxy, ..etc.).
>Hmmm.... but let's stay that you have no idea as to what the URI
>refers. It may refer to a person or a person or a galaxy... but for
>whatever reason you (or your agent) have no idea, a priori, all that
>you have is a (URI) name and a reference made using it (it's
>occurence in a 'text' sometimes aka webarch:Representation or it
>having been typed into the 'address bar' of a semantic web browser).
>
>Where do we go from here with such little information (just the name).
Well, most of the time, what you want to do is treat it as a
hyperlink. That is what the Web is for, after all. But that use has
nothing particularly to do with what it might *refer* to. So my
reaction would be, if you want to use a hyperlink, go ahead; but if
you want to know what it refers to, you need to get some knowledge
expressed in a form which uses the name *as a referring name* rather
than as a hyperlink. Thats a different kind of usage, but the SWeb
provides ways to do that.
>If, in the absense of other knowledge, we attempt to 'poke' (i.e.
>access) the thing referred to by giving the name to an HTTP engine
>and asking it to do a GET (sometimes called 'dereference' -
?? But what puzzles me is, why would one think that *the thing
referred to* can possibly be poked? We KNOW ahead of time that some
(most? almost all?) of these 'things referred to' cannot possibly be.
And suppose we do poke and get a response. What would we expect that
to tell us something about the *referent* of the name?
>which I'll agree does conflate (de-)reference and access) there is
>not much that HTTP itself can tell us about the resource.
Right, I wouldn't expect that HTTP would tell us anything about the
nature of things referred to at all. They (http and reference) seem
like totally unrelated matters. One has to do with transferring
information around a communication network, the other has to do with
the semantic meaning of names. Chalk and cheese.
>If what is referred to is
No, if what is poked is.... What is referred to is a completely
different matter.
>a webarch:InformationResource it can return a 200 status code and a
>webarch:Representation. Webarch 'defines' representation as a
>message - a sequence of bits/octets exchanged over a medium; IMO,
>something ephemeral - and something which itself generally has no
>URI. However, webarch is less clear about what the
>webarch:Representation is a representation of. Oh... the
>corresponding webarch:Resource...
Which might be anything at all: a person, book or galaxy. At which
point all talk of poking and http becomes fantasy.
If the webarch simply gave up on this absurd hubris of being a
general-purpose theory of language, and admitted that URIs are
hyperlinks to information sources, then the entire document would
make sense. But of course people and books and galaxies would not be
'resources'; just as they are not called "resources" in English or in
most of the early writings on which the Web is based (such as
Engelbart's).
>doh! Well, 'all of it'? or just 'its current state'? or a
>'description of it?' I find that I can 'muddle' along without quite
>having to ground that one out, but it does bother me from time to
>time.
It bothers me centrally and acutely. I cannot muddle along with a
confusion between things and their representations built into the
heart of the architecture. That distinction is absolutely central to
all semantics and semiotics. Getting it confused in the basic
beginners error that one learns to avoid in the first year of
graduate school. This is like asking a mathematician to muddle along
with 1 sometimes equal to 2, but sometimes not, whatever.
>Descriptions of a thing can clearly be 3rd party and have many
>origins - there may be many available descriptions of you or I with
>varying levels of veracity. A webarch:Representation (a text) that
>happens to contain a description could be self-describing (could
>make assertions about self) or be descriptive of a multiplicity of
>things (including itself or not).
True. But to do that it would have to have a name for itself, or use
some agreed-upon convention for referring to itself.
>But it is still not clear whether a text obtained by using the name
>of a thing to attempt to access the named thing where the text
>contains a description of the named thing
Look how confused that is.
(1) a text
(2) obtained by using the name to
(3) attempt to access the named thing
(4) where the text contains a description of the named thing.
Why would one expect to be able to even attempt to access a named
thing (3)? Most named or nameable things - in fact, virtually all, a
set whose complement is vanishingly small, of measure zero - aren't
the kind of thing that can possibly be accessed. Things have been
being named since humans first used spoken language, possible before.
Hyperlinks are the only kind of symbols that can be accessed in this
sense, and they have been in existence for less than my lifetime.
But in any case, why do you say that the attempt to use the name for
access, the thing that happens in (2), is an attempted access *of
the named thing* (3)? That is EXACTLY what you don't know when you
know nothing, whether what you are poking is what it refers to.
(Though it would be safe to bet a lot of money that it isn't, given
no information to the contrary, so it seems particularly wrongheaded
to make that assumption a priori, and have to use a Web access to
discover its false.)
The entire sentence presumes that the attempt to access does in fact
yield a text (1) which describes the thing named (4). And this text
is not itself the thing named (usually). So why did you characterize
the poke as an attempt to access the thing named? Surely the point is
that ALL one can EVER get back from ANY poke is a text (in some
rather broad sense of 'text' which includes images; something that
can be encoded in a byte stream), so why not make the basic
presumption that poking *never* gets you what is referred to, only
some kind of representation of it? And then, that the way to
determine what is being referred to, if you care about that, is to
examine this representation and see what it says. That is the best
you can hope to do in most human affairs.
>should be regarded as a webarch:Representation 'of the thing' or 'of
>a thing that describes the thing'. Of course I expect little
>sympathy over this "...you tell me what y'all want it to mean." :-)
>
>So... if what is being referred to happens to be (although we don't
>know this yet) a person or a book or a galaxy or an integer or a
>mathematical concept or whatever. Well, probably best not to arrange
>(through deployment of web infrastructure) for a 200 response
But I am planning to send back some information eventually, am I not?
So why not just damn well send it, then? Why all this web redirection
pussyfooting? The text itself is going to be the same whatever I do
with these http codes, and its only the text that can possibly
disambiguate what it refers to.
Suppose I am the engine that does the poking, and I am tag-savvy
enough to detect the 202 code, so I now 'know' that my URI refers to
an information resource. I, however, am a busy agent, and more codes
are coming soon, so I want to record this fact and attach it to the
document I just got back from my poke, so that other agents down the
line can know this useful piece of information I have discovered. How
do I do that? What can I SAY that will be useful to, say, an
inference engine which is looking at some document that uses my URI?
Unless there is an answer to this question, the http-range-14
decision is practically useless. And if there is an answer to the
question, then the obvious next question arises: why didn't we
require the source of the http response to provide this information
as part of the representation it emitted, rather that as some kind of
Web-masonic handshake?
>and a webarch:Representation to be returned in response to an
>attempt 'access' the named thing using HTTP. 404 Resource not found
>is not hugely helpful either in giving us an account of what was
>being referenced.
I don't think it is helpful *at all*. The chief problem with it is
that reference is a relationship between names used in a text or
representation, and things. So one would expect any disambiguation of
a name to be reflected, and signalled, by an actual text or
representation, not by an http code. Engines which examine the
representation eventually returned (such as a human looking at a
browser screen) won't even be aware of the http code traffic. What a
name refers to isn't something that has anything to do with transfer
protocols.
>Now the thing being referenced is amenable to description (however imperfect).
But look at how bad this mistake is. You have now concluded that the
thing referred to is "amenable to description" because it *isn't* an
information resource? No, it was ALWAYS amenable to description.
Descriptions don't care what kinds of thing they describe.
> So... instead of providing a webarch:Representation of the
>referenced thing, a webarch:Representation (a text) conveying a
>description of the referenced thing might be useful, and might be
>able to give us more definite information about the thing originally
>referenced by the name that we have. But wait a minute.... if we
>simply responded a webarch:Representation of such a description
>(which is but one of many possible descriptions - the sources of
>which we may trust to varying degrees - and which may be
>contradictory...) do we not risk confusing the referenced thing with
>the particular description (if any) that is returned.
>
>So... rather than arrange (through the deployment of web
>infrastructure) for a direct 200 response with a
>webarch:Representation containing a description of the referenced
>thing.... better to say no representation here
But why not?? Why should there be nothing useful here? Here I am, let
us suppose, with a URI intended to refer to a supernova, say SN
2006gy. Somewhere on the Web there is some definitive information
about SN 2006gy, perhaps similar to
http://chandra.harvard.edu/chronicle/0207/gentle/index.html
Now, what is the rationale for NOT putting this useful information at
the place where you would access it by using the URI to poke? Why
should it be somewhere else? That seems to make absolutely no sense.
>but you may find something of useful over there an provide another
>refering name that references a thing that (hopefully) describes
>(amongst other things) the thing that was referred to originally.
We start with a name N. There is a text T which uses this name and
therefore helps one to determine what the name refers to. OK so far.
We want to use the Web to link N, when used as an access request, to
some information which helps us determine what the name refers to.
Well, that seems like a no-brainer to me. Put T where N will access
it. This is in fact what we do already. It makes engineering and
semantic sense. It does not require indirection or fiddling with HTTP
codes.
The objection to this simple plan is that if we put T there, where
poking with N will access it, then we would be saying that N denotes
T itself. And THAT is a mistake, perhaps the central mistake, because
it confuses reference with access. That N accesses T does not mean
that N refers to T. That single mistake is the sole source of this
idiotic idea of using 303 redirects to encode an ill-defined
ontological distinction, as the only purpose of this is to obliterate
what should not be an assumption in the first place. If we were to
simply agree that reference and access are not identical, and to take
some care to state a more nuanced account of the relationship between
them, then millions of pointless 303 redirects could be avoided.
>This later is what the "303 see other" advice from the TAG is about.
>A corollary of following this advise is that you don't deploy
>webarch:Representations for people, places, books, galaxies etc.
>Instead you arrange that attempts to 'poke' the referenced thing
Look, that is crazy as stated. You cannot even attempt to poke a
galaxy. Galaxies aren't on the Internet.
>result in a visible (in the sense that the thing doing the poking is
>aware of it) redirection to something else that provides a
>description of the thin originally referenced.
All you can possibly get is a description in any case. What is
achieved by the indirection? Moreover, is it in fact the case that
the thing doing the poking *is* aware of it in the required sense? I
know the code is sent to the originator, but a redirect can be due to
many factors. How do I know that this redirect isn't a 'real'
redirect, but is a signal about the nature of the referent? Apart
from that problem, suppose I ignore the codes (which I should be able
to, since they are concerned only with details of http traffic) and
just look at the representation I get back from my original GET.
Where does it say *in that representation* anything about the nature
of the thing referred to? There is no reason why that text should
even use my original URI, is there?
>In all of this HTTP gives us no definitive means of 'knowing' that
>the referenced thing is *not* an information resource - it could be.
Indeed, which alone seems to me to make this entire redirection
business completely useless. I poke with a URI, which may or may not
denote an information resource. I see a 303 code. I have learned
nothing.
>But is does provide the means to 'bootstrap' a description of the
>referenced thing at the next layer up (eg. a narrative description
>for a human being or a machine readable description for a mechanised
>agent.
I don't understand the need for bootstrapping here. It seems like
using a tongs to pick up a tongs.
>
>[By 'you' in the above - I mean the person or entity that is
>establishing the association between a URI (which they have some
>presumed authority to associated with a thing) and a thing such that
>uses of the name as a reference are intended to refer to the
>associated thing.]
>
>Does this make any sense to you?
No. It seems to me to be a huge error, based on a basic semantic
mistake. I believe I can trace this mistake to the first time the Web
architectural theory equated URLs with URNs into a single category
and introduced the inherently ambiguous term 'identifier'.
The only ways to make a use of a name be a reference to a thing are
to use the name appropriately, or appeal to some kind of external
naming convention, or by using ostention (pointing at something and
saying 'that', or displaying something and saying 'this', etc..)
Transfer protocols are not the kind of thing that can do any of these
things.
> In the past I think you have referred to the TAG's "303 advice" as
>lunacy or words to that effect.
>
>For myself, though not a TAG member at the time, I find it quite
>appealing. It allows that HTTP URIs (with or without #'s) can be
>used to refer to any kind of thing
Allows? Of COURSE a name can be used to refer to any kind of thing.
It is silly to pretend otherwise. URIs could be used to refer to any
kind of thing even if the entire internet were to vanish in a cloud
of smoke. Reference has nothing to do with transfer protocols.
>, and in those cases where the thing is not a
>webarch:InformationResource it provides a means to obtain a
>(webarch:Representation of a) description of the referenced thing.
We already have such a means. It is called the Web.
>And... in the process provides for distingished URI names for the
>thing its description.
>
><snip/>
>
>>>However, in general, the Web doesn't
>>>provide any guaranteed way to know that in advance.
>>
>>Ah, but the semantic web does. If someone asserts
>>
>>http://ex:thingie rdf:type dc:author .
>>
>>and I have good reason to believe it, then I have good reason to
>>believe that 'http://ex:thingie' denotes a person.
>Ok... but how would you arrange to obtain such an assertion (from
>the web) armed only with the URI http://ex:thingie?
>>>It's not possible to
>>>know whether that which a URI identifies will respond to such a 'poke', by
>>>returning some material, without actually trying it.
>>
>>Wait. It isn't possible to know what you will get back by poking a
>>URI without trying the poke and seeing. Yes, true. But as to
>>whether what you are poking is the >referent< of the URI, that is a
>>different question. We know (see above) there must be cases where
>>it cannot possibly be, because what the URI refers to simply isn't
>>the kind of thing that can get poked in the required way.
>Ok... but in the 303 case, surely one can argue that what is poke'd
>is not the referent itself, but some proxy that has been placed by
>the entity that wishes to have the URI (name) associated with the
>referent.
You could, yes, but that is not what you and Noah described.
>I think that one could also argue that the same association could be
>established with the direct provision of the description, arguing
>that the responding resource stands proxy for the referent rather
>than being the referent. In this case one would choose not to care
>about the information/non-information nature of a resource (a choice
>that many would make - but some find the distinction important).
I think what is generally considered important is not the distinction
as such, but having some systematic way to both refer to information
resources and also to avoid ambiguity.
>I find some irony in that the introduction of the notion of an
>Information Resource was at least in part motivated as a response
>(with which I believe you were happy with - at least at some point
>in time) to some of your comments on Webarch.
Well, it was better than what went before. And I was getting tired
:-) And if it were (as I thought it was) simply a debate over
terminology, then the distinction is certainly useful and clarifying.
But to require that the entire fabric of Web traffic be warped to
signal this distinction seems like a very poor decision to me;
particularly as it does not get to the heart of the matter. It
objectifies the wrong distinction.
> Indeed think that you may even have said earlier in this thread
>that the distinction is a useful one to make.
I may have done, and I would stand by that. But I think it is being
misused here. The key distinction is between reference and
access/poking/retrieval. Getting this distinction clear is what is
required, not the distinction between pokable things and non-pokable
things. We should be able to refer to any kind of thing in the same
way.
>Maybe what you are 'objecting' to is the provision of any mechanism
>to signal such a distinction in HTTP... and the mechanism advised by
>the TAG is only partial in any case, given that (if you buy into it)
>it can only signal for certain that a referent is an information
>resource.
>>So yes, the only way to tell what the accessible thing (if there is
>>one) does is to poke it and see; but that is irrelevant to
>>questions of reference. Neither the thing poked nor what it sends
>>back in return need be what the URI >denotes< or >refers to<. This
>>is one good reason why we need to distinguish between what you get
>>when you poke with it, and what it refers to. They need not be the
>>same. I think that if the SWeb ever takes off (or begins to slide
>>downhill, using Tim's bobsled metaphor) then *most* URIs will be
>>like this.
>>
>>>Now, I agree with you that it could well be described as crazy to make
>>>subsequent attempts to access something via the Web that you already know
>>>is 'physical'. But using the core facilities provided by the Web, it's not
>>>possible to know that for sure without attempting that first access.
>>
>>Im not sure if RDF and Web ontologies count as 'core', but I am
>>assuming them to be part of the Web.
>
>Ok.... but somehow you still have to have obtained that first
>assertion that tells you that the referent of http://example.or/JC
>is in fact a foaf:Person, and have chosen to believe it. Armed with
>some persistence of that assertion, yes, one need never need to go
>there again. And yes, I agree that you may have happened upon this
>assertion without ever having to have 'poked' http://example.org/JC,
>and so you need never need to go there to find out some fact about
>the referent. But, what of the case, at the beginning, where all you
>have is a name. What are your strategies for finding out something?
Why do you need to find out anything (about the referent, that is)?
Absent any SWeb-style assertions, you never do. In fact, all URIs
could have no referents whatever, and nothing would be changed.
>There may be many... but one 'obvious' one is an attempted a direct access.
Again, this seems to me to be utterly non-obvious. Its as though
someone were to say, one way to find out what a name means is to
write it on a piece of brown paper and then turn around three times
while holding it. Why would you expect to be able to find out what a
name *refers to* by doing any kind of access? Unless of course that
access is likely to return some information about the thing named,
hopefully using the name itself to refer to it. But that is just a
web page, right?
>; another is to ask someone that you trust.
>
>>>Some systems may, of course, provide mechanisms for making assertions
>>>about URIs that can help avoid the need to attempt an access in order to
>>>find out about what is being referenced.
>>
>>Without some such making of assertions, it is impossible to either
>>determine or record what kind of entity a URI is being used to
>>refer to.
>>
>>>But since URIs are universal,
>>>other more general systems, encountering such URIs, may attempt access
>>>because they are unaware of that additional information and hence don't
>>>know any better.
>>
>>Isnt that what 404 errors are for?
>>
>>>Only by attempting an access can they find out anything
>>>more about the resource.
>>
>>Again, I think this is a mistake. Failure of access tells you that
>>some information isn't in the place you thought it might be, given
>>its name. That isn't the same kind of question as asking what the
>>name denotes. If the denoted resource is a person or a book, you
>>cannot possibly find out anything by attempting to access it, other
>>than it cannot be accessed. (And of course there can be any number
>>of other reasons why it cannot be accessed.) Notice Im
>>distinguishing here between poking blindly to see what happens, and
>>'attempting to access' a particular thing.
>>
>>>You are probably aware that the behaviour
>>>associated with attempts to access URIs that identify physical things
>>>occupies a large part of the httpRange-14 finding on which the TAG is
>>>currently working.
>>
>>Yes, and I think that this finding is profoundly flawed. (BTW,
>>non-information resources do not have to be physical: for example,
>>fictional characters cannot be poked, and neither can integers or
>>relations or classes.)
>>
>>>Ok, so now I'd better try and phrase the questions. First, does it sound,
>>>from what I've written here, as though I understood your response
>>>correctly, or have I simply missed the point?
>>
>>I think you have missed my point, yes. You seem to be working on
>>the assumption that the only way to discover whether a URI >refers
>>to< something is to use it to access (and if it succeeds, then it
>>refers to the [source of the] retrieved data, more or less), i.e.
>>that successful access determines reference, which is exactly what
>>I am arguing should NOT be assumed.
>
>I think we would only argue that attempted access is 'A' way of
>'POSSIBLE' discovery of "whether a URI >refers to< something".
OK, fair enough, I overstated somewhat. But I think its a little
stronger than you say here. If I get a 202 code, then I have an
authoritative signal that this URI really does denote that particular
information resource. According to http-range-14, successful
202-direct access is a (perhaps the only) form of Web baptism: it
strongly associates a name with its intended referent.
>FWIW, I'm also of the opinion that what you find out by poking may
>conflict with many other potential sources of 'discovery' and how
>you then sort out what you then believe... is something we have been
>(and probably will remain) silent about.
>>
>>>Second, if I have understood
>>>your response, does this throw any light on why it's important that
>>>attempts to access physical things identified by URIs need to be supported
>>>by the Web in order for there to be a general mechanism by which it is
>>>possible to discover that the thing is indeed physical?
>>
>>Im afraid not. Why does the current (non-semantic) Web care what a
>>URI refers to, and whether or not that thing is physical?
>I don't think that it does... and I think that for many who have
>observed this debate in all its forms over the past few years, we
>are indeed to many, well angels, dancing on the head of a pin.
>
>What IS important to some is that the referent of a URI is invariant
>between the 'classic' Web and the Semantic Web. That they are not
>two distinct systems, but one, and thus the refering names of the
>Semantic Web are not entirely free names that could be bound to
>anything - but are constrained by the bindings imposed by the
>classic web.
Well, I will agree with this, but only on the understanding that it
is vacuous, because the classic Web simply has had no architectural
connection with matters of reference. The access bindings are not
related to references.
>
>>Suppose I were to suggest that the Web suffers from a vitality
>>crisis, in that some URIs refer to living things and others do not,
>>and it is vital for HTTP engines to distinguish these, so any HTTP
>>GET should emit a special error code (909) to signal that its
>>referent is alive. This is almost exactly similar to the
>>httpRange-14 finding, and almost exactly as silly.
>Er...well, no actually... as you have remarked yourself, the 303
>advice does *not* infact say that referent is alive... the 200/303
>advice (of itself, if followed) only ever tells you that something
>is (at the moment!) an Information Resource (should that be of
>interest to you).
OK, sorry, I should have used the inverse. But my rhetorical point
still stands.
>>The Web without the SWeb simply does not concern itself with
>>semantic questions of reference >>at all<<. They do not arise.
>:-) Well, yes and no... the odd person will come to the point of
>wondering whether or not statements are being made about the actual
>weather in Oaxaca or merely a weather report about the same.
Its usually pretty easy to tell from the context of use, which gets
me to another of my hobby horses... but not here.
>Yes the technology of the web doesn't care - it only become an issue
>when people start to say things about what URI's refer to (from
>their pov). People have been making such assertions informally since
>before the Semantic Web - and yes, the Web itself didn't care
>whether they were wrong or right.
Quite. And we should be vary cautious taking what people say
informally at face value, since people are in fact often rather
sloppy about reference.
http://en.wikipedia.org/wiki/Deferred_reference
>>It is concerned only with moving chunks of information from place
>>to place (and archiving them, and so forth: I do not mean to
>>suggest this is all trivial or not worth serious effort to properly
>>design.) Reference is a semantic notion, concerned with what the
>>names in the texts refer to. These have nothing to do with one
>>another. That http-Range-14 is even being discussed by the TAG at
>>all is a symptom of a confusion between two distinct notions, both
>>of which are being referred to by the word 'identifies'
>Take the people away I guess we agree. However, in a hyper text
>document there is presumably some intention in the placement of a
>hypertext reference. The person making the reference in authoring
>the document has some sense of what the referent is
Virtually all the cases I have seen of hyperlinks whose surface form
is a referring noun or noun phrase are links to some kind of
definitive information source (often a Wikipedia entry or similar)
*about* the referent. That is, they seem to be intended to convey
that one will access not the referent, but a
description/representation-of/text-about the referent. Now, follow
that intuitive idea of the relationship between access and reference,
and ask yourself how well http-range-14 corresponds to it.
>- and to greater or lesser extent is trying to convey that sense to
>any one that happens to read their work. Yes... I agree that the
>'system' of the classic web is ignorant of all that - but it's
>users (both authors and consumers) are not.
OK. But I am pretty certain that if you ask users of the classical
web what they expect to get when they use a link, they will talk
about web pages, texts, images, etc.. They will in fact talk about
*representations* of what the names in their hypertext refer to. They
will not expect to be connected by the Web to actual referents. And
in those cases (relatively rare) where they are talking about the
actual website, or the web page, I suspect that they are using the
kind of indirect or deferred reference that people often do
informally without necessarily being aware of it. In other words, the
http-range-14 decision gets the 'normal' case exactly backwards. Most
people (not centrally concerned with Web architecture) rarely want to
*refer* to actual websites.
Pat
>>
>>Do you see my point?
>
>I think so....
>>
>>>Very best wishes
>>
>>and to you
>>
>>Pat
>>
>>>Rhys Lewis
>>
>>PS. That reads like a Welsh name. I have happy memories of an early
>>childhood in Maesteg, in the Llynfi valley.
>Best Regards
>
>Stuart Williams
>--
>
>Hewlett-Packard Limited registered Office: Cain Road, Bracknell,
>Berks RG12 1HN
>Registered No: 690597 England
--
---------------------------------------------------------------------
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
Received on Monday, 9 July 2007 19:58:15 UTC