Re: [Fwd: RE: "information resource"]

> > The problem seems to all come from when the idea of resource is
> > de-anchored from the Web so that a "resource" can mean anything. I have
> > no problem per se with that, but just am pointing out that some of
> > the reasons people are looking into ideas such as "information
> > resource" are because problems of authority and representation
> > are a lot trickier off the Web than on the Web, or when the two 
> > intermix
> > such as in the Semantic Web, where we have Web-statements about things
> > off the Web.
> 
> No, the problem is that they are exactly the same issues and folks
> just assume they are different because they don't understand the
> actual issues faced by current Web implementations of resources and
> how those issues impact what Web clients can assume about resources.
> Make Web statements about things on the Web and you have the same
> problems (and the same solutions) as those things off the Web.

It seems to me the problem is this: with RDF it becomes useful to
assign URIs to things like dogs and movies (even ones which are not
available for download).  When people do that, we easily get
unintended URI collisions, as discussed in the current draft:

      Suppose, for example, that one organization makes use of a URI
      to refer to the movie "The Sting", and another organization uses
      the same URI to refer to a discussion forum about "The Sting."
      This collision creates confusion about what the URI identifies,
      undermining the value of the URI. If one wanted to talk about
      the creation date of the resource identified by the URI, for
      instance, it would not be clear whether this meant "when the
      movie created" or "when the discussion forum about the movie was
      created." 
          - http://www.w3.org/TR/2004/WD-webarch-20040816/#URI-collision

Some people seem to find the notion of "information resources" helps
them avoid this kind of modeling error, or detect when other people do
it.  In fact, an OWL reasoner will often be able to report an error
when someone accidentally uses the URI of a movie when they meant the
URI of a discussion forum -- as long as there is a sufficiently
detailed ontology involved.  In "the running_time of X is ...", if the
declared domain of running_time is movies, and someone uses the
discussion forum URI instead, software can detect that.

A fairly simple ontology which might help a lot is to divide the world
into things which are and are not information resources.   The World
Wide Web Consortium is not an information resource, but what
http://www.w3.org/ idenfities is, ....  so it becomes practical to
detect and report the error of someone using that URI to (directly)
identify that organization.    Some of us think that an HTTP "200 OK"
response on a GET or HEAD for some URI means it identifies an
information resource, so this process becomes even easier:  if someone
writes that they work for http://www.w3.org/, the type-error can be
detected by only know about "works for" -- nothing needs to have been
said about "http://www.w3.org/".

(I also tend to think 301, 302, and 307 imply that something is an
information resource, but too much good data (like foaf and dublin
core) breaks with that assumption, which is why I'm trying to get them
to switch to using 303 See Other, and for now my code does not make
such an assumption.)

So from a process perspective, having Information Resource defined
turns httpRange-14 into pretty much a Yes or No question, although I'm
still arguing that you have to do the dereference.  This is mostly for
practicality, since I don't see DC, FOAF, or RSS changing to use hash
URIs.   I sympathize with people who want to learn something about a
URI's resource (eg that it's an information resource) just by looking
at the text of the URI, but I think it's already too late to do that
with http.

        -- sandro

Received on Sunday, 17 October 2004 18:55:12 UTC