W3C home > Mailing lists > Public > www-tag@w3.org > August 2002

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

From: Bill de hÓra <dehora@eircom.net>
Date: Thu, 1 Aug 2002 09:31:46 +0100
To: "'Graham Klyne'" <GK@ninebynine.org>, "'Aaron Swartz'" <me@aaronsw.com>
Cc: "'Tim Berners-Lee'" <timbl@w3.org>, <www-tag@w3.org>
Message-ID: <000d01c23935$e00ea020$1fc8c8c8@mitchum>




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

 
Received on Thursday, 1 August 2002 04:33:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:53 UTC