text: Up to Design Issues
  Note: (2006). This architectural question has now been decided by the W3C TAG, in a compromise which I think works quite well, and is described in a later short note and a TAG finding..)
  This document explains why the author find it difficult to work in the alternative proposed philosophies. If it misrepresents those others' arguments, then it fails, for which I apologize in advance and will endeavor to correct.
  The WWW is a space of information objects. The URI was originally called a UDI, and originally all URIs identified information objects. Now, URI schemes exist which identify more or less anything (e.g. UUIDs) or electronic mailboxes (mailto:) but is we look purely at HTTP URIs, they define a web of information objects. Information objects -- perhaps in Cyc terms ConceptualWorks -- are normally things which
  I want to make it clear that such things are generic (See Generic Resources) -- while they are documents, they generally are abstractions which may have many different bit representations, as a function of, for example:.
  I'm going to refer to this as a document, because it needs a term and that is the best I have to date, but the reader should be sure to realize that this does not mean a conventional office document, it can be for example
  and so on, as limited only by our imagination..
  The folks who disagree with the model do so for a number of different arguments. This article, therefore will have to take them one by one but the ones which come to mind are as follows: document concepts tons", "Moby Dick was finished over a century ago" and "I left Moby Dick on the beach" without expecting to be misunderstood. So we won't use human language as a guide when defining unambiguously the question of what a URI identifies. If we want to do that on the Semantic Web, we will say "I work for the organization whose home page is.)
  Some argue the the URI which I associate with someone's home page actually identifies that person. They argue that conventionally people use the identifier to identify the person. However, consider another page put together by friends who found a photograph of the same person. A lot of content filtering systems would collect that URI and put put into their list. Even though the photo had many representations which different devices could download using content negotiation and/or CC/PP (color or black and white and versions of different resolutions) the URI itself would be listed as containing nudity. The public are very aware of different works on the web, even though they have the same topic..
  Conclusion so far: the idea that a URI identifies the thing the document is about doesn't work because we can only use a URI to identify one thing and we have and already do use it to identify documents on the web.
  So what's wrong with the URI being taken to identify whatever the owner says?
  Let's look at what we mean by identifies. When we say there is identity, that means that there is some form of sameness that we associate with the identifier. Now, for all the philosophical argument, we can never test the identity of an abstract thing. What we can test is a representation which has been returned by the server when given that URI. When we use aURI, and get back several possible representations of it, then what expectation do we have about those representations?
  Take the test case that I see the web page which has a picture of a car, and I see in the URI in the URI bar in the browser. I email you the URI, "you see, the car is a Toyota?". You click on the link. Your browser shows the same URI as mine in the "URL bar" but you see a table of the car's weight, length, height, color, and registration number. We are confused. The web didn't work because you didn't get the same information as me. I expected you to get the same information, basically. That is how the Web works. That is the expectation behind every hypertext link - that the follower of the link should get basically the same information as the person who made the link. I say, "basically" because I would not have cared whether you saw or JPEG or a GIF. It probably wouldn't have mattered if you had seen a lower resolution or even black-and-white copy of the picture. If you are visually impaired, you may have been able to manage with a well-written description of the picture. But the the essential information is the same, not just the subject of the page.
  So now we have put the four corners on the expectation we have of a URI -- that.
  So how can we break free of that line of reasoning? We can try throwing away the rule that a URI identifies only one thing.
  There are many levels of identification (representation as a set of bits, document, car which the web page is about) and the URI publisher, as owner of the URI, has the right to define it to mean whatever he or she likes.
  Well, this one is tempting from the point of view that the
  owner of an identifier should reign supreme when it comes to
  saying what it identifies. It is quite a logically consistent
  position to take. After all, isn't this the case with
  uuid's? And for a new scheme, this would be
  interesting. How can we do it though, with HTTP? the problem
  is an engineering one: I can't in practice use a URI until I
  have some definitive information from the publisher as to
  what it identifies.
  2.2.1 Default
  Why can't a URI default to identifying a web page until you know otherwise? Because the web is open and you will never know when you might lean some other information which will make the default incorrect. (You can't use such "closed world" reasoning).
  2.2.2 Web operation
  Why can't a URI identify a web page until you have done some well-defined operation -- such as HTTP HEAD or GET -- and checked for information in that? Well, that would certainly work logically. Suppose we we define a return code or HTTP header which means "abstract object requested". It would mean that every web application which deals with web pages as web pages would actually be working under an ambiguity, and RDF processors could be programmed to look for that special information. We can't retrofit the millions of web servers out there, I assume.
  I feel that there is a great benefit to fixing this question at the spec level. Otherwise, what happens?.
  There has been no way to do this before RDF, but then similarly no real need for it. (What, is this just a problem with RDF? No, it will happen with any webized knowledge representation system.). We really need to have communication in which two people use the same URI to mean the same thing. If there
  We could fix HTTP so that it would return me some extra semantic headers explaining the whole thing. And in the case that the URI was deemed to be some abstract thing, I would not have the option of recommending the web page. Too bad: it has no URI...
  Otherwise,we have to try another way of letting the URI mean sometimes one thing and sometimes another. Here is another.
  Actually the URI has to, like in English, identify these different things ambiguously. Machines have to disambiguate using common sense and logic
  This is possible in theory. It is a mess. It fails particularly spectacularly when a URI is used ambiguously to refer to a web page and the thing that web page is about, which happens to be another web page. Anyone can write anything about anything is a Web motto, but here it falls down. Anyone can write anything about anything except those things which might get confused with the document they are writing. It breaks the axiom that we mean the same thing by a URI - in all contexts. (And RDF has a model theory in which necessarily in any interpretation, a symbol always denotes one thing).
  Actually the URI has to, like in English, identify these different things ambiguously. Machines have to disambiguate using the fact that different properties will refer to different levels.
  One way of getting here is to start by considering that HTTP headers can be divided into those which refer to the representation (or the document) and those that refer to, say, a car or a donkey. We can look at all RDF properties and other attributes in other languages and divide them in in such a way. So, when I say " is a color photo", I am referring to the representation; when I say " used to work down the mill" I am referring to the person; when I say " was taken on a rainy day" I am revering to the original photograph, which is basically the representation of Albert.
  This one has the problem when a web page refers to a web page. It can still be pursued, by having different verbs for talking about ownership of the web page and ownership of the car. This is a classic example of the 2-level syndrome (see also Dictionaries in the Library). The basic fallacy is that you can make the system general by introducing a second level - a new set of attributes, properties, or whatever, which allow you to refer to the metadata of something separately from the thing itself. These systems either turn out to be just limited 2-level systems (like XML and DTDs) or have to be extended to be recursive in some way later on such that in fact the two levels become unnecessary.
  Actually the URI has to, like in English, identify these different things ambiguously. Machines have to disambiguate using extra information which will be provided in other ways along with the URI
  This twist now relies on sending extra information with a URI. Effectively, the URI scheme has now failed to identify anything by itself. Those most familiar URIs as used by HTML sometimes suggested adding new attributes to the anchor tags of HTML documents to disambiguate a reference. I guess it would work if HTML anchors were the only uses of URIs. By contrast, they are used in thousands of places and way, many of which I am unaware. The architecture, however, is not that way: the architecture of the WWW is that a URI is a global unambiguous identifier. Not a URI and something else.
  (The various designs such a WebDav's propfind which use HTTP methods apart from GET to retreive information suffer from this same problem. the information does not have a URI: it is not on the web.)
  Actually the URI has to, like in English, identify these different things ambiguously. Machines have to disambiguate them by context: A catalog card will talk about a document. A car catalog will talk about a car.
  This works in the short term, when the two contexts are disjoint groups who do not need to communicate. It is in fact the current state: the groups of people who use HTTP URIs to talk about documents, and those who have just started to use them to talk about abstract concepts haven't collided yet. (Well, they have in my code. I need to be able to model the metadata about an HTTP URI as that about a document, and it being a class at the same time doesn't jive.)
  It doesn't work in the long term because it breaks the axiom that a URI must identify one thing,
  They may have been used to identify documents up till now, but for RDF and the Semantic Web, we should change that and start to use them as the Dublin Core and RDF Core groups have for abstract concepts.
  I think that we would have to design a new URI scheme before we change things that much. That is tempting of course. But then -- building a semantic web out of what we have is tempting too. It was tempting to rehash TCP a little when making HTTP. It wasn't practical, and we would have lost a lot more than we would have gained. There is a lot to be said for using common technology. We've got an infrastructure of documents. We want to build an infrastructure of knowledge. Let's build it using the documents. We might find that the commonality with the web of human-readable information is a boon.
  An argument which surprised me is that yes, HTTP URIs identify documents, but in fact the frgament identifier must only be used to identify parts -- fragments -- of documents. This means that RDF cannot in fact use HTTP URI schemes at all. A completely different system would have to be put together -- either a new set of URIs, or RDF conventions in which the relationship to the part of a document in which something was described became explicit. In N3 this would like like
  [ is rdf:referent of <#fmyCar> ] [ is rdf:referent of <#color> ] [ is rdf:referent of <#blue> ]
  Of course, languages would quickly generate special syntax for this. Alternatively, the RDF system would built entirely on the understanding that we were referring always to that denoted by a given bit of document, not the bit of document itself. This would mean that there would be no way for the RDF system to refer to documents themselves directly.
  This is actually a consistent way of working. It would be a change only for those people who use RDF to talk about documents as documents. We could change. apologize again if I have misunderstood or misrepresented other's arguments in this process of this explanation of my own position.
  Tim Berners-Lee
  2002-07-28Z
  Q: But surely, if a document is identified by a namespace URI, then when we look up an RDF namespace will millions of words in it we will have too long a document to be practical!
  A: It is arguable, for such as situation, whether the namespace itself is more cumbersome to manage than the document is to deliver. You can make an analogy with hypertext: Isn't the model of retrieving a document going to be inefficient when the documents are huge? Answers are twofold in each case,
  Firstly, yes it is likely to be less convenient, but that is no reason to skew which is a good engineering design for the vast proportion of namespaces (or hypertext documents) which are not huge.
  Secondly, the HTTP protocol actually does have methods of retrieving parts of a large document.
  Q: It seems strange that an HTTP URI should be limited to referring to documents, but that all one has to add is this little hash mark and suddenly you say it can be used to identify anything.
  A: The hash is not a minor appendage to the URI: It is the most significant piece of punctuation in the whole URIref. The hash adds a whole new level of abstraction and specification! It is true that in a hypertext page and that page scrolled to a given point seem very similar. The same applies to a graphic chart and an object within that chart, especially when it is displayed in the context of the original document. So I suppose it may be a shock when the technique is used with a semantic web language to refer to not the document, but something which the document discusses. That does allow it to break out of the whole concept of documents and into -- anything. But no one promised the Semantic Web would be boring. :-)
  Q: I thought you said "anything should be able to have a URI"?
  Yes, and it should. There is nothing in the URI spec to say what an individual scheme should or should not be created to identify. A new URI scheme could for example be ale to identify anything. But here we are talking about HTTP URIs. And remember that with semantic web languages, you can use a URIref (very different from a URI) to identify anything, for example with HTTP and RDF.
  Q: But what about CGI scripts? Surely you don't mean the HTTP URI identifies the script?
  A: Of course not. When we talk about the "document" identified by a URI it is very often an virtual document produced by, for example, a CGI script. The URI identifies the document on the web, with no regard to the process which causes representations of it to be served.
  Q: Some HTTP URIs can be POSTed to. Can you still say they identify documents?
  A: Well,.
  Q: What do you mean by "identify", anyway, in Model Theory terms? (2003)
  The closest term used in Model Theory to the way I am using identify is denote. Model theory analyses communication and understanding by imagining a set of interpretations, where an interpretation is a mapping from a symbol to that which it denotes. Model theorists and linguists tend to complain that one cannot talk about the meaning of a term, as you can never know what anyone means by anything, you can only see how they react. A given agent may have many possible interpretations, but new information the agent believes which mentions a symbol will rule out interpretations with which are inconsistent with the symbol. By the process of exchange of a lot of information, one arrives at a state in which one behaves as though other agents has the effectively the same set of interpretations. Under these conditions, one can think of the thing identified by the symbol in the community as being the set of things denoted by the symbol in the interpretations which agents in the community are left with. There has been much more discussion of this process (which is the essence of the writing of a standard and the purpose of documents like this) in email on www-tag with Pat Hayes and others in 2003.The rest are from Aaron Swartz
  Q: Can you point to something in the spec that says HTTP URIs must identify a document?
  There are many answers. I can point to things which could be interpreted to say that. The HTTP spec defines resources as network data objects. To me that "data" indicates the information nature of the thing. It precludes, in most people's minds, a car or the Andromeda Galaxy.
  I could explain that, as I originally wrote the HTTP spec, that was the author's intent.
  But I think the fairest thing is to say that the spec was written it was not sufficiently clear about this particular ambiguity, and for reasons mentioned above, this hasn't been a problem until now.
  Q: Isn't it a little weird to start making pronouncements about the entire HTTP Web when neither the spec nor the other TAG members agree?
  Pronouncements about the whole Web are really important where they are needed. In that case the TAG has a duty to make them. And so do I. It seems to me that this assumption is one we have been implicitly making and are now breaking, in a way which will make the semantic web either inconsistent or much less efficient. The TAG members do not agree on this: that is why they asked my to write this document. It is written as a TAG action item about tag issue HTTPRange-14. Things get a lot weirder than that. ;-).
  Well, there you are... you want to be able to put something in your browser, then you must have a representation of it. So somewhere in the picture, representations aside, is a ConceptualWork. If the ConceptualWork is important, then it needs a URI, in my opinion. The alternatives are attractive when you start to look at them, but each has a different snag. I have tried to explain above.
  Q: How can you say that the Semantic Web can use the hash mark to make a URI-ref identify anything when the URI RFC is very clear that hash marks only work when you dereference the document.
  I wouldn't say that hash marks "only work when you deference a document" any more than your street address "only works when I visit you", or your date of birth "only worked when you were born". I can use your street address -- or your data of birth -- to help identify you. What the spec defines is a way of using this particular URI to get some information over the Internet. The whole web works by what someone recently referred to as a "confusion" between name and address. It isn't a confusion. It is a connection between two pieces of architecture without which the web would not be. Rethink. It is primarily a name. We have made a way of looking it up. So you don't have to look it up for the name to "work" as an identifier. Just as you don't go and look it up when someone quotes the RDF namespace -- it works because the same identifier identifies the same thing in any context. Looked up or not. The same thing is true for foo#bar. If the document foo is never served, one can still (if one owns it) talk about foo#bar with authority. It is of course good practice to serve documents.
  Q: Are all Semantic Web agents going to start dereferencing every document they hear about?
  No, any more than you have to dereference every hypertext link you see.
  Q: Isn't the Semantic Web broken if we have to start disagreeing with major specifications like this?
  This philosophy is quite consistent with the HTTP spec as it is.
  1) What does "" identify?
  When was the thing it identified last changed?
  Have you read the thing it identifies?
  2) What does "" identify?
  3) What does "" identify?
  4) What does "" identify?
  When was the thing identified last changed?
  What does the writing on Dan's car say?
  Answers: 1:3. 2:7 Note here the web tolerates vagueness along the axis of different representations of the same image, but not of semantic level between the image and the pipe. 3:1; 4:2
  @@@links
  Up to Design Issues
  Tim BL