Re: URI: Name or Network Location?

My apologies for rehashing this, but I'm not fully satisfied.  Yet.  Feel
free to slap me in the face if this has been resolved and I just have not
done the requisite reading.

It seems to me that the below statements get back to the problem which is
described in [CRISIS].  If a URI resolves to an information resource, what
is described, the concept behind the URI, or the information resource which
is returned when you dereference the URI?

Supposed I define an ex:TelevisionSeries called Sopranos and assign it a
URI:

<ex:TelevisionSeries rdf:about="http://www.hbo.com/Sopranos">
   <ex:Title>The Sopranos</ex:Title>
</ex:TelevisionSeries>

But then when you dereference the URI, you get back a webpage.  So what does
the URI refer to, the Sopranos, or a webpage *about* the Sopranos?

Maybe I want to make statements about the webpage:

<ex:Webpage rdf:about="http://www.hbo.com/Sopranos">
   <ex:homepageOf rdf:resource="http://www.hbo.com/Sopranos"/>
   <ada:accessibilityRating>Good</ada:accessibilityRating>
</ex:Webpage>

So "http://www.hbo.com/Sopranos" is both an ex:TelevisionSeries and an
ex:Webpage about itself.  That doesn't seem right.

OK, so maybe I change my URI so that it does not resolve:

"http://www.hbo.com/names/Sopranos"

And when you try to dereference it you get back 404.  That I can live with.
But, per the below, you are suggesting that the server fall back to
providing an RDF description of the URI.  So we are back to original problem
-- what is described, the TelevisionSeries or the information resource which
is returned.

So maybe we *don't* fall back to returning an RDF description and all I get
is 404.  And so I go ahead and issue an MGET to the server for the URI and
get back an RDF description.  That I *do* like, because I am essentially
saying "give me the metadata you have for this URI" rather than "give me a
representation of this URI".

--- Stephen

[CRISIS] http://www.ontopia.net/topicmaps/materials/identitycrisis.html



Patrick Stickler Wrote:

Though I'd go one step further (eventually, even if not at first) and
make that server URIQA enlightened, so that, for those resources which
have RDF descriptions, if folks dereference the URI, they get a metadata
description of the resource, rather than just a boilerplate response.

E.g., when you do an HTTP GET on http://sw.nokia.com/VOC-1/Vocabulary
there is no "typical" representation available for that resource, so
the URIQA enlightened server falls back to trying to provide a description
of that resource. If there weren't any description either,
it would return a 404 response (or could return a friendly boilerplate
response such as you describe above) but in this case, there is a 
description
so it returns the description as the representation (which it is).

If there *were* some other representation provided for typical GET
requests, you could still obtain that description either using MGET
or via a direct request to the http://sw.nokia.com/uriqa? portal.

But as a first step (or even only step) the approach you've adopted
is IMO the way to go, and leaves the door open to adding functionality
in the future.

Cheers,

Patrick

--




Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify us immediately by replying to the message and deleting it from
your computer. Thank you.  ThruPoint, Inc.