RE: [httpRange-14] What do HTTP URIs Identify?

Bill,

I can't fault this ... in particular, as far as RDF model theory goes, what 
you say rings true.

In his lengthy response to Tim's document, Roy suggested:
>The URI doesn't identify different things in different contexts.  It is,
>however, used for different purposes in different contexts.

I'm trying to figure if this helps any, but can't escape the idea that it 
merely shifts the terminology of the debate, not it's fundamental nature.

...

Are we asking the right questions?  Roy, Tim and others are quite insistent 
that a URI identifies a single concept, so is not ambiguous.  That seems 
like a useful stake-in-the-ground.

What are the possible problems that arise if we don't assume an HTTP URI 
denotes a document?

I think it comes down to:  how do we talk about the descriptive document at 
an HTTP URI as a concept separate from the conceptual thing the URI is 
defined (intended) to denote.  So if I define http://example.org/myCar to 
identify the concept of my car, the wheeled metal box that I drive about 
in, then by:

     <http://example.org/myCar> ex:colour ex:Red .

I am clearly describing said metal box.  In that case, I don't think RDF 
should assign any other meaning to that assertion.

Then how might I say that the web page, obtained by dereferencing 
<http://example.org/myCar>, that I use to describe my car is red?
(a) use a different property.  Possible, I suppose, but "Yuk".
(b) use a different object URI.  Also possible, I think, but even more "Yuk".
(c) use a different subject URI accessing a representation that happens to 
be identical to the description of my car.  Well, I guess that can 
work.  (I pretty much do that myself, today, with http://id.ninebynine.org/ 
and http://www.ninebynine.org/Ident/ )

While the model theory may allow the above statement to be true in 
interpretations where <http://example.org/myCar> denotes the planet Mars, 
there are other considerations that mean we want to implicitly restrict the 
interpretations when we use RDF.  I think you (and Tim) are arguing that 
the restriction is placed by the authority who controls the URI (the domain 
owner), and Roy is arguing that the restriction comes from actual use 
(which is preferably aligned with the URI owner's intent).

So what is the possible value of restricting the interpretation of http: 
URIs to web-accessible documents?  It seems more social than 
engineering.  Should socially motivated usage be embedded in Web 
architecture when it doesn't force a particular engineering choice?  Maybe 
the idea of HTTP URIs identifying documents is more usefully considered as 
the same kind of exhortation as "Cool URIs don't change"?

#g
--

At 09:31 AM 8/1/02 +0100, Bill de hÓra wrote:



> >>> #g said:
>
>     <http://example.org/myCar> ex:colour ex:Red .
>
>Suppose that I already know that ex:colour and ex:Red are to be
>interpreted
>as describing the colour of the subject resource in the way that we (as
>English speaking people) might expect.  Am I to conclude that:
>     the web page at <http://example.org/myCar> is substantially red? Or
>     a car described by the web page at <http://example.org/myCar> is
>substantially red?
> >>>
>
>Or the chintz described <http://example.org/myCar> is red. The name
><http://example.org/myCar> can potentially denote anything.
>
>And you answer is that it will be whichever is the resource. If you
>don't know, you need a way to ask the authority of example.org to
>disambiguate. But I imagine you could continue to crunch the inferences
>without doing so. Where you have to stop and think is when you merge
>graphs. If you want to get online for more data, it's probably to ask
>the authority what she's on about.
>
>As for documents versus things; imo it's a non-issue (read: I don't
>understand what the fuss is about). Documents are resources when they
>are identified with a URI; that makes them distinct from
>representations.  There is no web page at the server unless the
>authority says there is; what you see on the client is a representation
>and what or how the server stores and generates that representation is
>an implementation detail of the server. Partitioning the information
>space into documents and resources because of a legacy matter in HTTP
>modelling doesn't help anyone.
>
>regards,
>Bill de hÓra
>
>..
>Propylon
>www.propylon.com
>
>

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 1 August 2002 12:23:04 UTC