Re: SemWeb use case for issue httpRange-14

> > terms.  The real distinction is just whether you focus on the
> > collection of information from which the web server generates its
> > response or focus past the server, as Roy does, on the subject of that
> > information.
> 
> No, the real distinction is whether or not you can give a URI to
> something that doesn't exist yet.  You cannot do so if what you are
> naming is a document, whereas you can for a concept that is only bound
> to a representation at the time of a request.

Abstraction #33 says nothing about documents.  If I rephrased it to
use the word "document", it would be in the form of "living document"
or "maintainable document".  A lot of people, including you (it seems)
think of a document as a fixed artifact.  TimBL does not; he seems to
think of a document as a mutable thing.  One can exist unwritten, then
in draft form, then rewritten over the years.  It's common to talk
about the different drafts and published revisions of a book as the
same book, so I see his point.  This ambiguity makes me uncomfortable,
though, so I try to avoid the word "document".

I said:

 Abstraction 33: An http URI is most strongly associated with a
 repository or collection of information.  When you GET that URI, the
 bytes returned convey that information.

I never said the repository had be somehow materialized or available
at the point of name-assignment.  The bytes sent back to a client
during a successful HTTP GET are a serialization (in some language
like HTML+English, JPEG, or RDF/XML) of the information in the
repository at that time.

These repositories might also be called databases, database instances,
knowledge bases, files, data structures, objects (in an OOP system),
etc.  To a web designer they might be called web sites, or web pages.
(Many of these terms, especially "web page", suffer from the same
sense of immutability as "document"; people sometimes say a "I got a
different page" when the content has changed.   Even the word
"database" has the same ambiguity, although I think "DBMS instance" or
"database table" might be okay.)   

For me the clearest mental image is of a (virtual) location where
information might or might not be present; like a bulletin board, or
whiteboard, or a desk covered with papers.  The information present at
the location may change over time, but the location itself persists.
I sometimes call this the distinction between the "content" and the
"container".  URIs are attached (in abstraction 33) to a container.
(And the web client does not visit the location; it talks to a server
agent who is or pretends to be at the location.  The server observes
the information-content at the location and (when things go well)
describes it to the client.  Sometimes the server modifies the
information content on behalf of the client.)

It is these locations which search engines index, based on the content
available at the time of traversal.  "Cool URLs dont change" is about
keeping the container thematically consistent, so when people return
to a place, or arrive there on someone's recommendation, they get
roughly the intended experience.  So yes, the contents of the
repository may change over time and may be indexed and linked-to
before being actually made available.

I don't have a proper write-up of this model, but I do have two
currently-idle slightly-out-of-date drafts which talk about it in more
detail, for people who would like a more detailed exposition [1] [2].

> Use the technology and think about what it implies.  This is not just
> my opinion, it is my experience, and it isn't going to change.

The question here is what mental model of the web (if any) the TAG
should recommend that people use.  Experience can help you develop and
test a mental model, but it is does directly constitute one.  Many
educated and intelligent people used to believe they experienced the
sun moving around the earth and heavier things falling faster than
light ones.  And yes, they put Galileo on trial for heresy rather than
changing their minds, but that doesn't mean they were right.

Some of us, in trying to develop the semantic web, have observed
things about the web which make the mental model you suggest seem not
as accurate as it once did.  I understand if you're too busy to think
about new alternatives right now, but please don't claim they are
inferior just because your model has served you well enough so far.

(One observation you can reproduce by writing various formal
assertions about the URI "http://www.w3.org/Consortium/".  It turns
out that sometimes (as in EARL) you want to talk about some marked-up
text (the content), sometimes (as in ACLs) you want to talk about a
maintainable information-repository (the container) and sometimes (as
in the membership database) you want to talk about a consortium (the
subject).  If you say the URI is directly attached to the subject (as
in abstraction 102) and recognize that other URIs may well have the
same subject, it becomes impossible to assert things about the
container and its the contents.  If you use abstraction 33, you can
talk about all three.)

   -- sandro

[1] http://www.w3.org/2002/11/bees-and-ants/paper
[2] http://www.w3.org/2002/11/webarch4/v3

Received on Thursday, 2 January 2003 06:03:21 UTC