Re: Clarifying what a URL identifies (Four Uses of a URL)

"Roy T. Fielding" wrote:
>
> "Tim Berners-Lee" wrote:
> >
> > There are a number of reasons why I strongly prefer
> > the URI to identify the web page, and I have gone into
> > them elsewhere, for example in
> > http://www.w3.org/DesignIssues/HTTP-URI.html
> >
> > This is the crux of the HTTP range issue 14.
> > (There are other different issues related to fragment identifiers
> > and content negotiation.)
> 
> I agree that you have very good reasons for preferring to think
> of the resource as the web page rather than its subject.  However,
> that isn't a sufficient model to talk about the state-changes that
> can occur on the subject as a result of methods applied to the
> resource.  As long as it is desirable to use HTTP as a window into
> the universe of real objects, whether they be temperature control
> systems, robots, or gatways to other information systems, it isn't
> possible to limit http URIs to identifying virtual documents. Those
> things do exist and are both functional and desirable, and most
> importantly are identifiable via http URIs today.  It is therefore
> evident that an http URI does not *always* identify a Web page,
> regardless of anyone's preference.  We need to find some other
> solution to the issue.

I think that any URI (be it an http URI or else) allways is an address
for something that it makes sense to technically interact with. In the
case of http URIs this means that they are (IMO) allways addresses for
resources for which it makes sense to define what a GET, POST, PUT or
DELETE on them means.

With this approach a Web page *and* things such as "temperature control
systems, robots, or gatways to other information systems" both belong
to the same 'type' of resource by definition.

I also think that there is no need for another kind of resource in order
to build a semantic web on the foundations of REST. 

With this definition, most (if not all) resources are the concept of some
form of data that it makes sense to define manipulations on and that
potentially have a representation I can GET and 'look' at to find out what
the subject is that the resource is about. Because resources can (despite
their own right as the idea/concept of data) be about a certain subject, I
can use the resource's address (the URI) to identify abstract things such
as 'my car'.

All that is actually needed to handle these two different uses of a URI is
a syntactical construct that allows to clearly state how a URI is actually used,
as an address for a resource *or* as an indicator (or identifier) for an
abstract subject.

Example:

Making a statement about the Web page that lives at http://www.w3.org

<rdf:Description address="http://www.w3.org">
  <dc:Title>World Wide Web Consortium</dc:Title>
<rdf:Description>


Making a statement about the W3C (the URI is used
to state what the subject of the RDF object is. As a
human I can dereference the URI and the returned representation
can give me a clue what the subject actually is)

<rdf:Description subjectIndicator="http://www.w3.org">
  <foo:Director>Tim Berners-Lee</foo:Director>
  <foo:Member>Member Name 1</foo:Member>
   <!-- etc.. -->
<rdf:Description>


I think that this approach works, because I don't see any reason (nor any
sense) to define GET,POST,DELETE or PUT invocations on abstract concepts
(that are not ultimaly a concept for some form of data). I believe that the
abstract concepts are in a universe 'above' the REST state machine, that we
use to 

  - create representations of addressable data
    (in order to indicate what the abstract concepts are that we are
    talking about and to make statements about them (e.g. RDF documents))

  - get representations of addressable data to obtain 
    (in order to investigate what the subjects are that are made statements
    about in some knowledge representations)

  - pass knowlede representations around


Jan

 

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org

Received on Thursday, 23 January 2003 16:11:07 UTC