Review of new HTTPbis text for 303 See Other

[Karl Dubost-3]

Le 4 août 2009 à 06:24, Tim Berners-Lee a écrit :

>>> Basically we are adding a layer of meaning by fragmenting a  
>>> generic meaning:
>>> From "Resource" to "Document, Thing and Service". It seems like  
>>> going from
>>> abstract to more defined material things. This might help  
>>> momentarily but
>>> will just push the limit to the next iteration of "abuse", the  
>>> next layer of
>>> fragmentation.
>>
>
> This isn't fragmentation.

Hmm nothing negative in my word fragmentation. I meant Resource being  
specialized in terms of the context.

> I am only talking about "Resource", not about other terms,
> and the problem is simply that it has been used differently in  
> different specs and sometimes ambiguously.

As in different meanings? or a generic meaning covering everything aka
a Resource can be a Thing, a Resource can be a Document, a Resource  
can be a Service. (which is what I meant)


>
>> We call this "categorization". It doesn't fragment, it organizes.

what I meant.

>> With the organization come benefits: predictability, auditability,
>> understandability.

as long as we share the same understanding for the organization, yes.

[John Black-3]

For years I have felt passionately about the technological-magic power
of the URI that names the Document that it also retrieves. I have agreed
with people who argued that it should be preserved above all.

My own opinion for all these years was that this magical combining of
naming with retrieving should also, if it only could, be extended to
other Things as well. And I spent a good bit of time researching the
question of how the sense of  "that-which-is-identified-by-a-URI", its
meaning or its denotation, could somehow be represented in such a way
that it could be returned by a URI over the web with some of the power
of the URI that simultaneously names *and* retrieves the Document it names.

But today, I am abandoning that hope. Instead, I now believe that it was
the original belief that was wrong. That URIs *retrieve* a Document
doesn't make the URI the only or best or obvious name for that Document
because Retrieval doesn't establish the
"that-which-is-identified-by-a-URI", the denotation or meaning, any
better than other means of representation. So the naming of Documents
has no magic solution over the naming of any other Thing.

Once I abandon the belief that Retrieval somehow establishes the Name of
that Retrieved, this whole discussion seems moot: HTTPrange-14, 303s,
the definition of Resource, Information Resource, Document are
unnecessary if the you see that HTTP retrieval is not the perfect way to
establish the "that-which-is-identified-by-a-URI" of a URI.

IMHO (arguments supporting these propositions pending).


John Black
www.kashori.com

[Ian Davis-5]

On Tue, Aug 4, 2009 at 5:57 AM, Alan Ruttenberg<alanruttenberg@...>
> If a HTTP URI can denote a person, then what is
> the verb DELETE supposed to do?

It doesn't do anything. You can't DELETE a person using HTTP just like
you can't GET a person using HTTP (or a representation of them). Same
goes for PUT and POST.

I find it easier to understand resources and information resources
using the semantics of PUT than I do with the semantics of GET: can
one alter the state of the resource using HTTP? The answer is true for
information resources and always false for non-information resources.

Ian

[Ian Davis-5]

Great summary Tim.

On Sun, Aug 2, 2009 at 3:14 AM, Tim Berners-Lee<timbl@...> wrote:

> Two snags occurred, as the years passed.  One was that a bunch of RDF users
> got the fact that it was good to use HTTP URIs, but didn't get the fact that
> you should put the foo.rdf online so that people can look up what #color
> means in it.  And as they didn't do that, they didn't actually bother with
> the "#" at all.  The second fly in the ointment was that some people wanting
> to use RDF for large systems found that they didn't want to use the "#".
> This was sometimes because the number of things defined in the same file was
> too low (like 1) or too large (like a million) and it was difficult to
> divide up the information into middle-sized chunks. Or they just didn't like
> the "#" because it looks weird. But for one reason or another people
> demanded the right to be able to use http://example.net/people/Pat to denote
> Pat rather than a web page about Pat.
> This potentially led to huge failures in the whole RDF world, with systems
> already built which just used   "http://example.net/people/Pat" to identify
> the document whether you like it or not.
> I among others pushed back against using non-hash URIs for arbitrary things
> his but eventually gave in.

Are we in a position to unify the  HTML and RDF fragment semantics so
we can safely content negotiate the two formats? Especially now we
have wider use of RDFa?

In http://www.w3.org/mid/5D85BD4B-C366-400C-B095-B13352D73F43@...
you suggested it was OK to negotiate these formats so long as the same
fragment was not not used as an anchor and a thing.

That's quite hard to achieve consistently in practice. As an example
see http://creativecommons.org/ns where
http://creativecommons.org/ns#Work is both an anchor and an rdfs:Class

Ian

[Graham Klyne-5]

Tim Berners-Lee wrote:
> In general POSTs to arbitrary things.   The case of POST to a list page
> creating a new page (from the posted content) and creating a entry in
> the list linking to the new content (like net news) I have not really
> seen used.

Isn't this exactly what AtomPub (and hence a system like Google Data) does?

It's certainly something that I'm planning to use in a data curation project I'm
working on.

I raise this as I'm mildly concerned by a possible implication that this isn't
really a good design, and that I'm oblivious to a better way to achieve this goal.

#g

[Julian Reschke]

Graham Klyne wrote:
> Tim Berners-Lee wrote:
>> In general POSTs to arbitrary things.   The case of POST to a list
>> page creating a new page (from the posted content) and creating a
>> entry in the list linking to the new content (like net news) I have
>> not really seen used.
>
> Isn't this exactly what AtomPub (and hence a system like Google Data) does?

It is.

> It's certainly something that I'm planning to use in a data curation
> project I'm
> working on.
>
> I raise this as I'm mildly concerned by a possible implication that this
> isn't
> really a good design, and that I'm oblivious to a better way to achieve
> this goal.
> ...

No, using POST to add to a collection is the right thing to do. An
alternative is PUT, in case you want to allow the client to specify the
name of the new sub resource.

BR, Julian

[noah_mendelsohn]

Tim Berners-Lee wrote:

> I would like to see what the documents all look like if edited to
> use the words Document and Thing, and eliminate Resource. That's my
> best bet as to two english words which mean as close as we can get
> to what we want.

Yes on "thing"; as you've heard me say from time to time, I continue to
have reservations about the word "document".  No doubt "document" seems
less intimidating than IR, and is often suggestive of what we mean. Still,
I think it's actually too narrow, or at least troublingly ambiguous.

Maybe I've hung out with the XML crowd to long, but one of the things that
I tend to think of as characteristic of "documents", as opposed to "data",
is that they tend to have ordered content.  The order of the paragraphs in
this email document is significant.

Now, let's say that I have a resource (thing) that consists of an
unordered set of stock quotes.  Each quote is a {company name, price}
pair, but there is no inherent or prefered order for the quotes.  As a
practical matter, any particular representation sent through HTTP will
likely have the quotes in one order or another, but that order is an
artifact of the representation technology, just like the angle brackets,
whitespace or other delimiters for the quotes.  I representation with the
order changed would be equally appropriate.

Question: is it OK to return a 200 for this bag of quotes?  I hope so.  Do
we call an unordered bag of quotes a document?  Well, we can, but I think
it's a stretch.

I played some role in suggesting the term "Information Resource" to the
TAG in 2004.  I acknowledge and regret that few seem to be pleased with
it, but let me at least remind those who don't know how it came about.  I
wanted to find a term that more clearly covered cases like the one above
(and relational tables, trees, graphs, and other data-like abstractions).
It occurred to me that Claude Shannon, in his theory of Information,
seemed to deal with exactly the sorts of abstractions for which we wanted
to allow 200;  I.e., those that could be represented by a sequence of
bits, of agreed encoding.   Can you apply Shannon's theory (which is
really about error rates and reliablity) to attempts to transmit the text
of the Gettysburg address?  Yes, presuming sender and receiver can agree
on an encoding.  Can you apply Shannon's theory to my bag of stock quotes
or to the information filling the (unordered!) rows and columns of a
relational table?  Yes.  Can you apply it to attempts to somehow transmit
me, the three dimensional living TAG member with the unruly hair?  No. So,
it's just the distinction we want.

If everyone decides that on balance "document" is the lesser of the evils,
I suppose I could go along with it, but I don't think it's quite right. If
we use it, we should at least try to explain what's really covered and
what's not.  I still think that IR, in the sense intended, is closer to
what we really mean.  (If I have to return a 303 for a bag of stock
quotes, I'm going to be annoyed.)

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Tim Berners-Lee <timbl@...>
Sent by: www-tag-request@...
08/01/2009 10:14 PM
 
        To:     Pat Hayes <phayes@...>
        cc:     "Roy T. Fielding" <fielding@...>, Larry Masinter
<masinter@...>, Julian Reschke <julian.reschke@...>, Mark
Nottingham <mnot@...>, W3C TAG <www-tag@...>, (bcc: Noah
Mendelsohn/Cambridge/IBM)
        Subject:        Historical - Re: Proposed IETF/W3C task force:
"Resource meaning" Review of new HTTPbis text for 303 See Other



On 2009-07 -20, at 16:27, Pat Hayes wrote:
[...]

. But this thread started because HTTPbis explicitly disagrees with RFC
3986 on what a resource is. Surely these various documents should at least
agree on their uses of the basic technical terminology.

I agree.

Historically, URIs were used to point to thinks like web pages and files
and movies, on the web, useful documents, or "online resources" in the
sense of useful things out there. FTP. Gopher and HTTP sites served up
various types of online resources.  People got used to http://example.com/ 
being a web page and http://example.com/#contact being an anchor within
it.

The Online Information community, into whose domain the web stuff was put
for standardization at the IETF, referred to these things like web pages
as resources, and changed the original "D" for "Document"  in "UDI" to
"R".
Some felt that resource was more appropriate term, maybe because
"document" wasn't wide enough to include things like movies.

Now the URI spec actually allowed URIs for completely different things,
such as telephone end points, and wisely the URI spec does not make any
arbitrary constraint on what a resource should be, especially a resource
denoted by a URI in a new scheme to be invented.

Meanwhile, the HTTP spec was polished and elaborated basically as a
document delivery system, plus other methods for updating documents, plus
POST.  (POST started historically as a way of introducing a new web page y
posting it to a list, just as in NNTP.  It then almost immediately got
used as a catch-all extension method. I will ignore it in this overview).

There was no real definition of what a resource or document was -- maybe
because it seemed obvious. The HTTP spec did not even specify whether the
URI denoted a person or a document about them, it just explained that the
thing returned representation of the resource.

Roy's REST work then came along to formalize HTTP as REST and declared
that a resource was a time-varying mapping between URI and representation.
That was good enough for HTTP. It didn't have enough for the AWWW, when it
came along, to be able to describe how the web worked.

In fact, the AWWW document, to explain how to use the web properly, had to
add in a bunch of stuff about the social expectations -- things like, yes,
the mapping from URI to representation is a function of time, but not just
any old one -- a random function is not typically very useful. There are
expectations about it can change with time.  Persistence, consistency,
with various common patterns which allow the web to be a useful medium.
The AWWW decided to use the term "Information Resource" for a thing like a
web page which contains information, and "Resource" for any old thing at
all.

So HTTP and the REST work of was done very much in this space of document
delivery, editing and update.  There was no philosophical need to talk
about what he URI denoted (the person, the web page about the person)
until RDF came along, when there was an immediate need.

When RDF was first developed, it was motivated by the need for data about
resources very much in the online information sense: data about documents,
or 'metadata'.  In fact it was designed to be able to describe anything,
but many early users of RDF referred to it as metadata technology.  RDF
used the word "resource" rather awkwardly in fact as it turned out.  In
the beginning, many of the things being described were documents, and so
the online information meaning of resource made sense. But in fact in RDF
the resource was allowed to be anything at all. A class, rdf:Resource even
used the term as the universal class of all things.  A little later, the
Web Ontology Language decided to use Thing for that.

RDF came along in what I think was a neat way.  It used completely
existing web protocol extension devices to introduce a new system which
was fundamentally different from the old HTTP+HTML one.  The HTML web was
a hypertext model, which pages and anchors. The RDF model was a knowledge
representation one of arbitrary things.  It did this by using the fact
that a new language can define whatever it likes as what a local
identifier denotes.  A graphic language might use local identifier to
denote lines and points. HTML used local identifiers to identify hypertext
anchors.  RDF used them to identify arbitrary concepts, people, whatever.

The web architecture gave all these languages a common way of building a
global identifier for the thing denoted by a local identifier in a given
document.   The semantics of the hash sign are defined web-wide to mean
that "a#b" can be used to denote whatever is denoted by "b" in the
document denoted by "a".

Worked a treat.  At the beginning of the century, people played around and
gave all kinds of things URIs like "http://example.com/foo.rdf#color".
Some of us did lots of work and made all kinds of systems which exchanged
and integrated data in this way.

Two snags occurred, as the years passed.  One was that a bunch of RDF
users got the fact that it was good to use HTTP URIs, but didn't get the
fact that you should put the foo.rdf online so that people can look up
what #color means in it.  And as they didn't do that, they didn't actually
bother with the "#" at all.  The second fly in the ointment was that some
people wanting to use RDF for large systems found that they didn't want to
use the "#". This was sometimes because the number of things defined in
the same file was too low (like 1) or too large (like a million) and it
was difficult to divide up the information into middle-sized chunks. Or
they just didn't like the "#" because it looks weird. But for one reason
or another people demanded the right to be able to use
http://example.net/people/Pat to denote Pat rather than a web page about
Pat.

This potentially led to huge failures in the whole RDF world, with systems
already built which just used   "http://example.net/people/Pat" to
identify the document whether you like it or not.
I among others pushed back against using non-hash URIs for arbitrary
things his but eventually gave in.

So in response to this, the HTTP protocol was, in fact, changed.

The spec wasn't changed.  The spec editors were not brought on board to
the new model.  The spec was interpreted.  The TAG negotiated in a way a
truce between the existing HTTP spec, RDF systems, and people who wanted
to use HTTP URIs without "#" to identify people.  That truce was
HTTPRange-14, which said that yoiu don't a priory know that a hashless
HTTP URI denoted a document, but if the server responded with a 200 then
you did, and you had a representation of the document.   If you did a get
on one of these new URIs which identified things were not documents
(people, RDF properties, classes, etc) them the server must not return
200, it can return 303 pointing to a document which explains more.

So the HTTP protocol was, effectively,  changed.  The HTTP protocol as
extended now allows HTTP to be used not only for Documents but for
arbitrary Things.  It extends the set of things which you can ask a web
server about from documents to anything.  It isn't a very bad design, nor
very beautiful.  Other designs would have worked, but that one was the
only one which didn't have major problems for some community.  It could be
extended, but basically it works. It would be very expensive to reverse it
in terms of systems which have been deployed.

It is also very expensive to go on debating it as though it is an open
issue. It is reasonable to try to make the documents more consistent.

Anyway, that is a simplified version of the history of all this as I saw
it.

I would like to see what the documents all look like if edited to use the
words Document and Thing, and eliminate Resource. That's my best bet as to
two english words which mean as close as we can get to what we want. Note
however that the web is a new system, a design in which new concepts are
created, so we can't expect english words to exist to capture exactly the
concepts. So we take those nearby and abuse them as little as we can as
far as we can tell at the time, and then write them in initial caps to
recognize that that is what we have done.

Tim

[Michael K. Bergman]

Hi All,

I don't know whether they would accept the commission (as I have
suggested before [1]), but I again suggest the TAG appoint Roy
Fielding and Pat Hayes to work jointly to present to the TAG a
resolution to these vexing terminology and semantics issues.

Further, if the TAG were to agree in advance to accept a
consensus recommendation from them, I think that goodwill and
intelligence will prevail. I, for one, would agree to the
recommendation.

Thanks, Mike

[1]
http://www.mkbergman.com/426/the-shaky-semantics-of-the-semantic-web/

noah_mendelsohn@... wrote:

> Tim Berners-Lee wrote:
>
>> I would like to see what the documents all look like if edited to
>> use the words Document and Thing, and eliminate Resource. That's my
>> best bet as to two english words which mean as close as we can get
>> to what we want.
>
> Yes on "thing"; as you've heard me say from time to time, I continue to
> have reservations about the word "document".  No doubt "document" seems
> less intimidating than IR, and is often suggestive of what we mean. Still,
> I think it's actually too narrow, or at least troublingly ambiguous.
>
> Maybe I've hung out with the XML crowd to long, but one of the things that
> I tend to think of as characteristic of "documents", as opposed to "data",
> is that they tend to have ordered content.  The order of the paragraphs in
> this email document is significant.
>
> Now, let's say that I have a resource (thing) that consists of an
> unordered set of stock quotes.  Each quote is a {company name, price}
> pair, but there is no inherent or prefered order for the quotes.  As a
> practical matter, any particular representation sent through HTTP will
> likely have the quotes in one order or another, but that order is an
> artifact of the representation technology, just like the angle brackets,
> whitespace or other delimiters for the quotes.  I representation with the
> order changed would be equally appropriate.
>
> Question: is it OK to return a 200 for this bag of quotes?  I hope so.  Do
> we call an unordered bag of quotes a document?  Well, we can, but I think
> it's a stretch.
>
> I played some role in suggesting the term "Information Resource" to the
> TAG in 2004.  I acknowledge and regret that few seem to be pleased with
> it, but let me at least remind those who don't know how it came about.  I
> wanted to find a term that more clearly covered cases like the one above
> (and relational tables, trees, graphs, and other data-like abstractions).
> It occurred to me that Claude Shannon, in his theory of Information,
> seemed to deal with exactly the sorts of abstractions for which we wanted
> to allow 200;  I.e., those that could be represented by a sequence of
> bits, of agreed encoding.   Can you apply Shannon's theory (which is
> really about error rates and reliablity) to attempts to transmit the text
> of the Gettysburg address?  Yes, presuming sender and receiver can agree
> on an encoding.  Can you apply Shannon's theory to my bag of stock quotes
> or to the information filling the (unordered!) rows and columns of a
> relational table?  Yes.  Can you apply it to attempts to somehow transmit
> me, the three dimensional living TAG member with the unruly hair?  No. So,
> it's just the distinction we want.
>
> If everyone decides that on balance "document" is the lesser of the evils,
> I suppose I could go along with it, but I don't think it's quite right. If
> we use it, we should at least try to explain what's really covered and
> what's not.  I still think that IR, in the sense intended, is closer to
> what we really mean.  (If I have to return a 303 for a bag of stock
> quotes, I'm going to be annoyed.)
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Tim Berners-Lee <timbl@...>
> Sent by: www-tag-request@...
> 08/01/2009 10:14 PM
>  
>         To:     Pat Hayes <phayes@...>
>         cc:     "Roy T. Fielding" <fielding@...>, Larry Masinter
> <masinter@...>, Julian Reschke <julian.reschke@...>, Mark
> Nottingham <mnot@...>, W3C TAG <www-tag@...>, (bcc: Noah
> Mendelsohn/Cambridge/IBM)
>         Subject:        Historical - Re: Proposed IETF/W3C task force:
> "Resource meaning" Review of new HTTPbis text for 303 See Other
>
>
>
> On 2009-07 -20, at 16:27, Pat Hayes wrote:
> [...]
>
> . But this thread started because HTTPbis explicitly disagrees with RFC
> 3986 on what a resource is. Surely these various documents should at least
> agree on their uses of the basic technical terminology.
>
> I agree.
>
> Historically, URIs were used to point to thinks like web pages and files
> and movies, on the web, useful documents, or "online resources" in the
> sense of useful things out there. FTP. Gopher and HTTP sites served up
> various types of online resources.  People got used to http://example.com/ 
> being a web page and http://example.com/#contact being an anchor within
> it.
>
> The Online Information community, into whose domain the web stuff was put
> for standardization at the IETF, referred to these things like web pages
> as resources, and changed the original "D" for "Document"  in "UDI" to
> "R".
> Some felt that resource was more appropriate term, maybe because
> "document" wasn't wide enough to include things like movies.
>
> Now the URI spec actually allowed URIs for completely different things,
> such as telephone end points, and wisely the URI spec does not make any
> arbitrary constraint on what a resource should be, especially a resource
> denoted by a URI in a new scheme to be invented.
>
> Meanwhile, the HTTP spec was polished and elaborated basically as a
> document delivery system, plus other methods for updating documents, plus
> POST.  (POST started historically as a way of introducing a new web page y
> posting it to a list, just as in NNTP.  It then almost immediately got
> used as a catch-all extension method. I will ignore it in this overview).
>
> There was no real definition of what a resource or document was -- maybe
> because it seemed obvious. The HTTP spec did not even specify whether the
> URI denoted a person or a document about them, it just explained that the
> thing returned representation of the resource.
>
> Roy's REST work then came along to formalize HTTP as REST and declared
> that a resource was a time-varying mapping between URI and representation.
> That was good enough for HTTP. It didn't have enough for the AWWW, when it
> came along, to be able to describe how the web worked.
>
> In fact, the AWWW document, to explain how to use the web properly, had to
> add in a bunch of stuff about the social expectations -- things like, yes,
> the mapping from URI to representation is a function of time, but not just
> any old one -- a random function is not typically very useful. There are
> expectations about it can change with time.  Persistence, consistency,
> with various common patterns which allow the web to be a useful medium.
> The AWWW decided to use the term "Information Resource" for a thing like a
> web page which contains information, and "Resource" for any old thing at
> all.
>
> So HTTP and the REST work of was done very much in this space of document
> delivery, editing and update.  There was no philosophical need to talk
> about what he URI denoted (the person, the web page about the person)
> until RDF came along, when there was an immediate need.
>
> When RDF was first developed, it was motivated by the need for data about
> resources very much in the online information sense: data about documents,
> or 'metadata'.  In fact it was designed to be able to describe anything,
> but many early users of RDF referred to it as metadata technology.  RDF
> used the word "resource" rather awkwardly in fact as it turned out.  In
> the beginning, many of the things being described were documents, and so
> the online information meaning of resource made sense. But in fact in RDF
> the resource was allowed to be anything at all. A class, rdf:Resource even
> used the term as the universal class of all things.  A little later, the
> Web Ontology Language decided to use Thing for that.
>
> RDF came along in what I think was a neat way.  It used completely
> existing web protocol extension devices to introduce a new system which
> was fundamentally different from the old HTTP+HTML one.  The HTML web was
> a hypertext model, which pages and anchors. The RDF model was a knowledge
> representation one of arbitrary things.  It did this by using the fact
> that a new language can define whatever it likes as what a local
> identifier denotes.  A graphic language might use local identifier to
> denote lines and points. HTML used local identifiers to identify hypertext
> anchors.  RDF used them to identify arbitrary concepts, people, whatever.
>
> The web architecture gave all these languages a common way of building a
> global identifier for the thing denoted by a local identifier in a given
> document.   The semantics of the hash sign are defined web-wide to mean
> that "a#b" can be used to denote whatever is denoted by "b" in the
> document denoted by "a".
>
> Worked a treat.  At the beginning of the century, people played around and
> gave all kinds of things URIs like "http://example.com/foo.rdf#color".
> Some of us did lots of work and made all kinds of systems which exchanged
> and integrated data in this way.
>
> Two snags occurred, as the years passed.  One was that a bunch of RDF
> users got the fact that it was good to use HTTP URIs, but didn't get the
> fact that you should put the foo.rdf online so that people can look up
> what #color means in it.  And as they didn't do that, they didn't actually
> bother with the "#" at all.  The second fly in the ointment was that some
> people wanting to use RDF for large systems found that they didn't want to
> use the "#". This was sometimes because the number of things defined in
> the same file was too low (like 1) or too large (like a million) and it
> was difficult to divide up the information into middle-sized chunks. Or
> they just didn't like the "#" because it looks weird. But for one reason
> or another people demanded the right to be able to use
> http://example.net/people/Pat to denote Pat rather than a web page about
> Pat.
>
> This potentially led to huge failures in the whole RDF world, with systems
> already built which just used   "http://example.net/people/Pat" to
> identify the document whether you like it or not.
> I among others pushed back against using non-hash URIs for arbitrary
> things his but eventually gave in.
>
> So in response to this, the HTTP protocol was, in fact, changed.
>
> The spec wasn't changed.  The spec editors were not brought on board to
> the new model.  The spec was interpreted.  The TAG negotiated in a way a
> truce between the existing HTTP spec, RDF systems, and people who wanted
> to use HTTP URIs without "#" to identify people.  That truce was
> HTTPRange-14, which said that yoiu don't a priory know that a hashless
> HTTP URI denoted a document, but if the server responded with a 200 then
> you did, and you had a representation of the document.   If you did a get
> on one of these new URIs which identified things were not documents
> (people, RDF properties, classes, etc) them the server must not return
> 200, it can return 303 pointing to a document which explains more.
>
> So the HTTP protocol was, effectively,  changed.  The HTTP protocol as
> extended now allows HTTP to be used not only for Documents but for
> arbitrary Things.  It extends the set of things which you can ask a web
> server about from documents to anything.  It isn't a very bad design, nor
> very beautiful.  Other designs would have worked, but that one was the
> only one which didn't have major problems for some community.  It could be
> extended, but basically it works. It would be very expensive to reverse it
> in terms of systems which have been deployed.
>
> It is also very expensive to go on debating it as though it is an open
> issue. It is reasonable to try to make the documents more consistent.
>
> Anyway, that is a simplified version of the history of all this as I saw
> it.
>
> I would like to see what the documents all look like if edited to use the
> words Document and Thing, and eliminate Resource. That's my best bet as to
> two english words which mean as close as we can get to what we want. Note
> however that the web is a new system, a design in which new concepts are
> created, so we can't expect english words to exist to capture exactly the
> concepts. So we take those nearby and abuse them as little as we can as
> far as we can tell at the time, and then write them in initial caps to
> recognize that that is what we have done.
>
> Tim
>
>
>
>
>
>
>
>
>
>
>

--
__________________________________________

Michael K. Bergman
CEO  Structured Dynamics LLC
319.621.5225
skype:michaelkbergman
http://structureddynamics.com
http://mkbergman.com
http://www.linkedin.com/in/mkbergman
__________________________________________

[ray denenberg]

I try to follow this as closely as I can, and I try to stay out of the
discussion as much as possible.  But I'd like to weigh-in on "document". I
don't like it.

It was once explained to me that "document" applies to a resource  that is
relatively stable - relative for example to one which is updated regularly.
Thus for example http://www.loc.gov/  (Library of Congress home page)  is a
document but http://weather.yahoo.com/forecast/USDC0001.html  (DC weather)
is not.  That's not to say that the LC home page doesn't change, but it is
*relatively* stable.   (On Noah's  stock quote example, a stock quote web
page would not be a document by this quasi-definition. A "bag of stock
quotes" would.)

This explanation was given at the very first Dublin Core meeting (Dublin
Ohio, March 1995), and the framers themselves were uncomfortable with
"document" so they crafted the term "Document Like Object", DLO,  which was
popular for awhile but ultimately abandoned, because nobody could really
figure out what it was, just like nobody really knows what a document is.
Now you may say that "document" in the current context isn't intended to
mean this at all, but to many of us it will always have that connotation.

Is "document" being tossed around because of dissatisfaction with
"information resource"?  On one hand there has been a failure to define
"information resource" to everyone's satisfaction, but on the other hand
there is still a desire to definitionally represent the difference between
information resource and  non-information resource.  Do people think there
will be more success if we start over and use "document" instead?
Personally I'd stick with  "information resource".

--Ray

----- Original Message -----
From: <noah_mendelsohn@...>
To: "Tim Berners-Lee" <timbl@...>
Cc: "Roy T. Fielding" <fielding@...>; "Julian Reschke"
<julian.reschke@...>; "Larry Masinter" <masinter@...>; "Mark
Nottingham" <mnot@...>; "Pat Hayes" <phayes@...>; "W3C TAG"
<www-tag@...>
Sent: Monday, August 24, 2009 8:24 PM
Subject: Re: Historical - Re: Proposed IETF/W3C task force: "Resource
meaning" Review of new HTTPbis text for 303 See Other

> Tim Berners-Lee wrote:
>
>> I would like to see what the documents all look like if edited to
>> use the words Document and Thing, and eliminate Resource. That's my
>> best bet as to two english words which mean as close as we can get
>> to what we want.
>
> Yes on "thing"; as you've heard me say from time to time, I continue to
> have reservations about the word "document".  No doubt "document" seems
> less intimidating than IR, and is often suggestive of what we mean. Still,
> I think it's actually too narrow, or at least troublingly ambiguous.
>
> Maybe I've hung out with the XML crowd to long, but one of the things that
> I tend to think of as characteristic of "documents", as opposed to "data",
> is that they tend to have ordered content.  The order of the paragraphs in
> this email document is significant.
>
> Now, let's say that I have a resource (thing) that consists of an
> unordered set of stock quotes.  Each quote is a {company name, price}
> pair, but there is no inherent or prefered order for the quotes.  As a
> practical matter, any particular representation sent through HTTP will
> likely have the quotes in one order or another, but that order is an
> artifact of the representation technology, just like the angle brackets,
> whitespace or other delimiters for the quotes.  I representation with the
> order changed would be equally appropriate.
>
> Question: is it OK to return a 200 for this bag of quotes?  I hope so.  Do
> we call an unordered bag of quotes a document?  Well, we can, but I think
> it's a stretch.
>
> I played some role in suggesting the term "Information Resource" to the
> TAG in 2004.  I acknowledge and regret that few seem to be pleased with
> it, but let me at least remind those who don't know how it came about.  I
> wanted to find a term that more clearly covered cases like the one above
> (and relational tables, trees, graphs, and other data-like abstractions).
> It occurred to me that Claude Shannon, in his theory of Information,
> seemed to deal with exactly the sorts of abstractions for which we wanted
> to allow 200;  I.e., those that could be represented by a sequence of
> bits, of agreed encoding.   Can you apply Shannon's theory (which is
> really about error rates and reliablity) to attempts to transmit the text
> of the Gettysburg address?  Yes, presuming sender and receiver can agree
> on an encoding.  Can you apply Shannon's theory to my bag of stock quotes
> or to the information filling the (unordered!) rows and columns of a
> relational table?  Yes.  Can you apply it to attempts to somehow transmit
> me, the three dimensional living TAG member with the unruly hair?  No. So,
> it's just the distinction we want.
>
> If everyone decides that on balance "document" is the lesser of the evils,
> I suppose I could go along with it, but I don't think it's quite right. If
> we use it, we should at least try to explain what's really covered and
> what's not.  I still think that IR, in the sense intended, is closer to
> what we really mean.  (If I have to return a 303 for a bag of stock
> quotes, I'm going to be annoyed.)
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>

[noah_mendelsohn]

Mike Bergman writes:

> I don't know whether they would accept the commission (as I have
> suggested before [1]), but I again suggest the TAG appoint Roy
> Fielding and Pat Hayes to work jointly to present to the TAG a
> resolution to these vexing terminology and semantics issues.

I think I speak for the TAG in saying that we welcome constructive
proposals from anyone in the community, and that would include Roy and/or
Pat, should they decide to offer any in this area.  From a process point
of view, the TAG doesn't "appoint" anyone other than TAG members to do
work like this, though we do sometimes accept offers from people who want
to work with us.  I expect that Roy and Pat have seen your suggestion.
They both know the TAG and its ways very well, and if they wanted to
undertake work on this, they'll know how to coordinate appropriately.

> Further, if the TAG were to agree in advance to accept a
> consensus recommendation from them, I think that goodwill and
> intelligence will prevail. I, for one, would agree to the
> recommendation.

Honestly, I don't think this suggestion properly reflects the role of the
TAG.  The TAG adds value when it offers a considered review of the pros
and cons of particular drafts or other proposals.  We can't do that by
agreeing in advance, even to suggestions from people as well respected as
Roy and Pat.

Noah
W3C TAG co-chair

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Mike Bergman <mike@...>
08/24/2009 09:01 PM
 
        To:     noah_mendelsohn@...
        cc:     Tim Berners-Lee <timbl@...>, "Roy T. Fielding"
<fielding@...>, Julian Reschke <julian.reschke@...>, Larry
Masinter <masinter@...>, Mark Nottingham <mnot@...>, Pat Hayes
<phayes@...>, W3C TAG <www-tag@...>
        Subject:        Re: Historical - Re: Proposed IETF/W3C task force:
"Resource meaning" Review  of new HTTPbis text for 303 See Other


Hi All,

I don't know whether they would accept the commission (as I have
suggested before [1]), but I again suggest the TAG appoint Roy
Fielding and Pat Hayes to work jointly to present to the TAG a
resolution to these vexing terminology and semantics issues.

Further, if the TAG were to agree in advance to accept a
consensus recommendation from them, I think that goodwill and
intelligence will prevail. I, for one, would agree to the
recommendation.

Thanks, Mike

[1]
http://www.mkbergman.com/426/the-shaky-semantics-of-the-semantic-web/

noah_mendelsohn@... wrote:

> Tim Berners-Lee wrote:
>
>> I would like to see what the documents all look like if edited to
>> use the words Document and Thing, and eliminate Resource. That's my
>> best bet as to two english words which mean as close as we can get
>> to what we want.
>
> Yes on "thing"; as you've heard me say from time to time, I continue to
> have reservations about the word "document".  No doubt "document" seems
> less intimidating than IR, and is often suggestive of what we mean.

Still,
> I think it's actually too narrow, or at least troublingly ambiguous.
>
> Maybe I've hung out with the XML crowd to long, but one of the things
that
> I tend to think of as characteristic of "documents", as opposed to
"data",
> is that they tend to have ordered content.  The order of the paragraphs
in
> this email document is significant.
>
> Now, let's say that I have a resource (thing) that consists of an
> unordered set of stock quotes.  Each quote is a {company name, price}
> pair, but there is no inherent or prefered order for the quotes.  As a
> practical matter, any particular representation sent through HTTP will
> likely have the quotes in one order or another, but that order is an
> artifact of the representation technology, just like the angle brackets,

> whitespace or other delimiters for the quotes.  I representation with
the
> order changed would be equally appropriate.
>
> Question: is it OK to return a 200 for this bag of quotes?  I hope so.
Do
> we call an unordered bag of quotes a document?  Well, we can, but I
think
> it's a stretch.
>
> I played some role in suggesting the term "Information Resource" to the
> TAG in 2004.  I acknowledge and regret that few seem to be pleased with
> it, but let me at least remind those who don't know how it came about. I

> wanted to find a term that more clearly covered cases like the one above

> (and relational tables, trees, graphs, and other data-like
abstractions).
> It occurred to me that Claude Shannon, in his theory of Information,
> seemed to deal with exactly the sorts of abstractions for which we
wanted
> to allow 200;  I.e., those that could be represented by a sequence of
> bits, of agreed encoding.   Can you apply Shannon's theory (which is
> really about error rates and reliablity) to attempts to transmit the
text
> of the Gettysburg address?  Yes, presuming sender and receiver can agree

> on an encoding.  Can you apply Shannon's theory to my bag of stock
quotes
> or to the information filling the (unordered!) rows and columns of a
> relational table?  Yes.  Can you apply it to attempts to somehow
transmit
> me, the three dimensional living TAG member with the unruly hair?  No.
So,
> it's just the distinction we want.
>
> If everyone decides that on balance "document" is the lesser of the
evils,
> I suppose I could go along with it, but I don't think it's quite right.
If

> we use it, we should at least try to explain what's really covered and
> what's not.  I still think that IR, in the sense intended, is closer to
> what we really mean.  (If I have to return a 303 for a bag of stock
> quotes, I'm going to be annoyed.)
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Tim Berners-Lee <timbl@...>
> Sent by: www-tag-request@...
> 08/01/2009 10:14 PM
>
>         To:     Pat Hayes <phayes@...>
>         cc:     "Roy T. Fielding" <fielding@...>, Larry Masinter
> <masinter@...>, Julian Reschke <julian.reschke@...>, Mark
> Nottingham <mnot@...>, W3C TAG <www-tag@...>, (bcc: Noah
> Mendelsohn/Cambridge/IBM)
>         Subject:        Historical - Re: Proposed IETF/W3C task force:
> "Resource meaning" Review of new HTTPbis text for 303 See Other
>
>
>
> On 2009-07 -20, at 16:27, Pat Hayes wrote:
> [...]
>
> . But this thread started because HTTPbis explicitly disagrees with RFC
> 3986 on what a resource is. Surely these various documents should at

least
> agree on their uses of the basic technical terminology.
>
> I agree.
>
> Historically, URIs were used to point to thinks like web pages and files

> and movies, on the web, useful documents, or "online resources" in the
> sense of useful things out there. FTP. Gopher and HTTP sites served up
> various types of online resources.  People got used to
http://example.com/ 
> being a web page and http://example.com/#contact being an anchor within
> it.
>
> The Online Information community, into whose domain the web stuff was
put
> for standardization at the IETF, referred to these things like web pages

> as resources, and changed the original "D" for "Document"  in "UDI" to
> "R".
> Some felt that resource was more appropriate term, maybe because
> "document" wasn't wide enough to include things like movies.
>
> Now the URI spec actually allowed URIs for completely different things,
> such as telephone end points, and wisely the URI spec does not make any
> arbitrary constraint on what a resource should be, especially a resource

> denoted by a URI in a new scheme to be invented.
>
> Meanwhile, the HTTP spec was polished and elaborated basically as a
> document delivery system, plus other methods for updating documents,
plus
> POST.  (POST started historically as a way of introducing a new web page
y
> posting it to a list, just as in NNTP.  It then almost immediately got
> used as a catch-all extension method. I will ignore it in this
overview).
>
> There was no real definition of what a resource or document was -- maybe

> because it seemed obvious. The HTTP spec did not even specify whether
the
> URI denoted a person or a document about them, it just explained that
the
> thing returned representation of the resource.
>
> Roy's REST work then came along to formalize HTTP as REST and declared
> that a resource was a time-varying mapping between URI and
representation.
> That was good enough for HTTP. It didn't have enough for the AWWW, when
it
> came along, to be able to describe how the web worked.
>
> In fact, the AWWW document, to explain how to use the web properly, had
to
> add in a bunch of stuff about the social expectations -- things like,
yes,
> the mapping from URI to representation is a function of time, but not
just
> any old one -- a random function is not typically very useful. There are

> expectations about it can change with time.  Persistence, consistency,
> with various common patterns which allow the web to be a useful medium.
> The AWWW decided to use the term "Information Resource" for a thing like
a
> web page which contains information, and "Resource" for any old thing at

> all.
>
> So HTTP and the REST work of was done very much in this space of
document
> delivery, editing and update.  There was no philosophical need to talk
> about what he URI denoted (the person, the web page about the person)
> until RDF came along, when there was an immediate need.
>
> When RDF was first developed, it was motivated by the need for data
about
> resources very much in the online information sense: data about
documents,
> or 'metadata'.  In fact it was designed to be able to describe anything,

> but many early users of RDF referred to it as metadata technology.  RDF
> used the word "resource" rather awkwardly in fact as it turned out.  In
> the beginning, many of the things being described were documents, and so

> the online information meaning of resource made sense. But in fact in
RDF
> the resource was allowed to be anything at all. A class, rdf:Resource
even
> used the term as the universal class of all things.  A little later, the

> Web Ontology Language decided to use Thing for that.
>
> RDF came along in what I think was a neat way.  It used completely
> existing web protocol extension devices to introduce a new system which
> was fundamentally different from the old HTTP+HTML one.  The HTML web
was
> a hypertext model, which pages and anchors. The RDF model was a
knowledge
> representation one of arbitrary things.  It did this by using the fact
> that a new language can define whatever it likes as what a local
> identifier denotes.  A graphic language might use local identifier to
> denote lines and points. HTML used local identifiers to identify
hypertext
> anchors.  RDF used them to identify arbitrary concepts, people,
whatever.
>
> The web architecture gave all these languages a common way of building a

> global identifier for the thing denoted by a local identifier in a given

> document.   The semantics of the hash sign are defined web-wide to mean
> that "a#b" can be used to denote whatever is denoted by "b" in the
> document denoted by "a".
>
> Worked a treat.  At the beginning of the century, people played around
and
> gave all kinds of things URIs like "http://example.com/foo.rdf#color".
> Some of us did lots of work and made all kinds of systems which
exchanged
> and integrated data in this way.
>
> Two snags occurred, as the years passed.  One was that a bunch of RDF
> users got the fact that it was good to use HTTP URIs, but didn't get the

> fact that you should put the foo.rdf online so that people can look up
> what #color means in it.  And as they didn't do that, they didn't
actually
> bother with the "#" at all.  The second fly in the ointment was that
some
> people wanting to use RDF for large systems found that they didn't want
to
> use the "#". This was sometimes because the number of things defined in
> the same file was too low (like 1) or too large (like a million) and it
> was difficult to divide up the information into middle-sized chunks. Or
> they just didn't like the "#" because it looks weird. But for one reason

> or another people demanded the right to be able to use
> http://example.net/people/Pat to denote Pat rather than a web page about

> Pat.
>
> This potentially led to huge failures in the whole RDF world, with
systems
> already built which just used   "http://example.net/people/Pat" to
> identify the document whether you like it or not.
> I among others pushed back against using non-hash URIs for arbitrary
> things his but eventually gave in.
>
> So in response to this, the HTTP protocol was, in fact, changed.
>
> The spec wasn't changed.  The spec editors were not brought on board to
> the new model.  The spec was interpreted.  The TAG negotiated in a way a

> truce between the existing HTTP spec, RDF systems, and people who wanted

> to use HTTP URIs without "#" to identify people.  That truce was
> HTTPRange-14, which said that yoiu don't a priory know that a hashless
> HTTP URI denoted a document, but if the server responded with a 200 then

> you did, and you had a representation of the document.   If you did a
get
> on one of these new URIs which identified things were not documents
> (people, RDF properties, classes, etc) them the server must not return
> 200, it can return 303 pointing to a document which explains more.
>
> So the HTTP protocol was, effectively,  changed.  The HTTP protocol as
> extended now allows HTTP to be used not only for Documents but for
> arbitrary Things.  It extends the set of things which you can ask a web
> server about from documents to anything.  It isn't a very bad design,
nor
> very beautiful.  Other designs would have worked, but that one was the
> only one which didn't have major problems for some community.  It could
be
> extended, but basically it works. It would be very expensive to reverse
it
> in terms of systems which have been deployed.
>
> It is also very expensive to go on debating it as though it is an open
> issue. It is reasonable to try to make the documents more consistent.
>
> Anyway, that is a simplified version of the history of all this as I saw

> it.
>
> I would like to see what the documents all look like if edited to use
the
> words Document and Thing, and eliminate Resource. That's my best bet as
to
> two english words which mean as close as we can get to what we want.
Note
> however that the web is a new system, a design in which new concepts are

> created, so we can't expect english words to exist to capture exactly
the

> concepts. So we take those nearby and abuse them as little as we can as
> far as we can tell at the time, and then write them in initial caps to
> recognize that that is what we have done.
>
> Tim
>
>
>
>
>
>
>
>
>
>
>

--
__________________________________________

Michael K. Bergman
CEO  Structured Dynamics LLC
319.621.5225
skype:michaelkbergman
http://structureddynamics.com
http://mkbergman.com
http://www.linkedin.com/in/mkbergman
__________________________________________

[Pat Hayes]

I agree that 'document' has too much baggage attached to it, and  
triggers too many existing assumptions. And 'Document Like Object' is  
hideous.

Maybe a better approach would be to focus on the role these things  
play in the actual network, rather than the nature of the beast. How  
about something like 'interfaced object' or 'network interfaced thing'  
or the like, to emphasize that these are entities that can be directly  
'attached' to the network. This seems to be the actual determining  
factor for being placed into this category, rather than anything about  
its essential nature. This would allow for example such very non-
document-like examples as the live feed from a webcam to be included.

Some possibilities along these lines:

"interfaced thing"   (blech)
"networked thing"   (also blech)
"resourced thing"   with the meaning that to 'resource' something is  
to (make it into a network-accessible resource by) interface(ing) it  
to the network. Abbreviates to "resource" , obviously :-)

Or, on a slightly different but obviously related tack:

"self-representing thing"   with the meaning that it is a thing that  
is the ultimate source of the representations of itself. Note the  
implied contrast here with things that may well have representations,  
but cannot also be the network source of those representations (eg  
galaxies as contrasted with stored JPEG images of galaxies.)

Or, given the analogy to a person whose only response to any question  
is to smile (code 200) and hand you a picture of himself; perhaps we  
should call these things "narcissistic", or "nar" for short, which  
could also be an acronym for "Network Accessible Resource" :-)

I have to confess that all of these suggestions strike me as too  
artificial; but maybe that will be an advantage, once we all get used  
to whatever phrase gets adopted. And I do like the general idea of  
focussing on the functionality rather than the metaphysics.

Pat Hayes


On Aug 25, 2009, at 7:17 AM, Ray Denenberg, Library of Congress wrote:

> I try to follow this as closely as I can, and I try to stay out of  
> the discussion as much as possible.  But I'd like to weigh-in on  
> "document". I don't like it.
>
> It was once explained to me that "document" applies to a resource  
> that is relatively stable - relative for example to one which is  
> updated regularly. Thus for example http://www.loc.gov/  (Library of  
> Congress home page)  is a document but http://weather.yahoo.com/forecast/USDC0001.html 
>   (DC weather) is not.  That's not to say that the LC home page  
> doesn't change, but it is *relatively* stable.   (On Noah's  stock  
> quote example, a stock quote web page would not be a document by  
> this quasi-definition. A "bag of stock quotes" would.)
>
> This explanation was given at the very first Dublin Core meeting  
> (Dublin Ohio, March 1995), and the framers themselves were  
> uncomfortable with "document" so they crafted the term "Document  
> Like Object", DLO,  which was popular for awhile but ultimately  
> abandoned, because nobody could really figure out what it was, just  
> like nobody really knows what a document is. Now you may say that  
> "document" in the current context isn't intended to mean this at  
> all, but to many of us it will always have that connotation.
>
> Is "document" being tossed around because of dissatisfaction with  
> "information resource"?  On one hand there has been a failure to  
> define "information resource" to everyone's satisfaction, but on the  
> other hand there is still a desire to definitionally represent the  
> difference between information resource and  non-information  
> resource.  Do people think there will be more success if we start  
> over and use "document" instead? Personally I'd stick with  
> "information resource".
>
> --Ray
>
> ----- Original Message ----- From: <noah_mendelsohn@...>
> To: "Tim Berners-Lee" <timbl@...>
> Cc: "Roy T. Fielding" <fielding@...>; "Julian Reschke" <julian.reschke@...
> >; "Larry Masinter" <masinter@...>; "Mark Nottingham" <mnot@...
> >; "Pat Hayes" <phayes@...>; "W3C TAG" <www-tag@...>
> Sent: Monday, August 24, 2009 8:24 PM
> Subject: Re: Historical - Re: Proposed IETF/W3C task force:  
> "Resource meaning" Review of new HTTPbis text for 303 See Other
>
>
>> Tim Berners-Lee wrote:
>>
>>> I would like to see what the documents all look like if edited to
>>> use the words Document and Thing, and eliminate Resource. That's my
>>> best bet as to two english words which mean as close as we can get
>>> to what we want.
>>
>> Yes on "thing"; as you've heard me say from time to time, I  
>> continue to
>> have reservations about the word "document".  No doubt "document"  
>> seems
>> less intimidating than IR, and is often suggestive of what we mean.  
>> Still,
>> I think it's actually too narrow, or at least troublingly ambiguous.
>>
>> Maybe I've hung out with the XML crowd to long, but one of the  
>> things that
>> I tend to think of as characteristic of "documents", as opposed to  
>> "data",
>> is that they tend to have ordered content.  The order of the  
>> paragraphs in
>> this email document is significant.
>>
>> Now, let's say that I have a resource (thing) that consists of an
>> unordered set of stock quotes.  Each quote is a {company name, price}
>> pair, but there is no inherent or prefered order for the quotes.  
>> As a
>> practical matter, any particular representation sent through HTTP  
>> will
>> likely have the quotes in one order or another, but that order is an
>> artifact of the representation technology, just like the angle  
>> brackets,
>> whitespace or other delimiters for the quotes.  I representation  
>> with the
>> order changed would be equally appropriate.
>>
>> Question: is it OK to return a 200 for this bag of quotes?  I hope  
>> so.  Do
>> we call an unordered bag of quotes a document?  Well, we can, but I  
>> think
>> it's a stretch.
>>
>> I played some role in suggesting the term "Information Resource" to  
>> the
>> TAG in 2004.  I acknowledge and regret that few seem to be pleased  
>> with
>> it, but let me at least remind those who don't know how it came  
>> about.  I
>> wanted to find a term that more clearly covered cases like the one  
>> above
>> (and relational tables, trees, graphs, and other data-like  
>> abstractions).
>> It occurred to me that Claude Shannon, in his theory of Information,
>> seemed to deal with exactly the sorts of abstractions for which we  
>> wanted
>> to allow 200;  I.e., those that could be represented by a sequence of
>> bits, of agreed encoding.   Can you apply Shannon's theory (which is
>> really about error rates and reliablity) to attempts to transmit  
>> the text
>> of the Gettysburg address?  Yes, presuming sender and receiver can  
>> agree
>> on an encoding.  Can you apply Shannon's theory to my bag of stock  
>> quotes
>> or to the information filling the (unordered!) rows and columns of a
>> relational table?  Yes.  Can you apply it to attempts to somehow  
>> transmit
>> me, the three dimensional living TAG member with the unruly hair?  
>> No. So,
>> it's just the distinction we want.
>>
>> If everyone decides that on balance "document" is the lesser of the  
>> evils,
>> I suppose I could go along with it, but I don't think it's quite  
>> right. If
>> we use it, we should at least try to explain what's really covered  
>> and
>> what's not.  I still think that IR, in the sense intended, is  
>> closer to
>> what we really mean.  (If I have to return a 303 for a bag of stock
>> quotes, I'm going to be annoyed.)
>>
>> Noah
>>
>> --------------------------------------
>> Noah Mendelsohn
>> IBM Corporation
>> One Rogers Street
>> Cambridge, MA 02142
>> 1-617-693-4036
>> --------------------------------------
>>
>>
>>
>>
>>
>>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[T.V Raman]

And fast-forwarding to the Web of today:

TimBL>    The semantics of the hash sign are defined web-wide  
TimBL> to mean that "a#b" can be used to denote whatever is denoted by "b" in  
TimBL> the document denoted by "a".


transmutes into

A#B  means pass B as an argument into whatever A  returns ---
this is how many AJAX-powered Web applications extend the meaning
of '#'. One could squint at this and pretend that  the earlier
behavior that Tim describes
fits into this new model by saying:

"Just believe that HTML pages with no script in them --- or
alternatively, HTML pages that didn't have a script in them that
consumed 'B' behave "as if there were a onLoad document handler
that put focus on B".
But I believe that interpretation is a mistake, because it goes
down the rat-hole of describing the meaning of content in terms
of user-agent vehavior.

--
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@...
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  raman@..., tv.raman.tv@...
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc