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
--------------------------------------








Tim Berners-Lee <timbl@w3.org>
Sent by: www-tag-request@w3.org
08/01/2009 10:14 PM
 
        To:     Pat Hayes <phayes@ihmc.us>
        cc:     "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter 
<masinter@adobe.com>, Julian Reschke <julian.reschke@gmx.de>, Mark 
Nottingham <mnot@mnot.net>, W3C TAG <www-tag@w3.org>, (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

Received on Tuesday, 25 August 2009 00:35:57 UTC