[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Are URIs Resources? (WAS RE: Re: Non-infoset)


Re:  Are URIs Resources? (WAS RE:  Re: Non-infoset)

Bullard, Claude L (Len) wrote:
> That's the critical observation for this and many other
> threads that rely on ontological commitment to sustain
> communications.
>
> Would anyone care to compare that to URIs as a unit of
> information:
>
> 1.  Is a URI a resource?

No.  There is no such thing as a "resource".

To elaborate on that:  There are two groups that have
spent a lot of time and energy trying to figure out
what a "resource" is, and both have come to the same
conclusion:  We don't know what a "resource" is, and we
don't really care either.

For lack of a better name I'll call these "the REST camp" and
"the RDF camp".  In the REST camp's worldview, "resources"
are formally and explicitly left undefined -- you can GET
a representation of one, or you can POST an entity to one,
or do a number of other things, but you can never get your
hands on the resource itself.  It's a convenient fiction.

In the RDF camp's worldview, you don't do anything with
resources either except Identify them and Describe them.
REC-rdf-mt even goes so far as to say that:

| The semantics does not assume any particular relationship
| between the denotation of a URI reference and a document
| or Web resource which can be retrieved by using that URI
| reference in an HTTP transfer protocol, or any entity which
| is considered to be the source of such documents. [...] The
| things denoted are called 'resources', following [RFC 2396],
| but no assumptions are made here about the nature of resources;
| 'resource' is treated here as [...] a generic term for anything
| in the universe of discourse.

In other words: we don't know, and we don't really care either.


> 2.  If it is a resource, what operations are significant?

See above.  There is no such thing as a resource.


> 3.  Are URIs ever ambiguous?

Yes, but only if you go out of your way to make them so.

You can follow the REST camp and treat them as mostly-opaque
identifiers, perform GETs, POSTs, and DELETEs, and never
worry at all about the shape of the URI itself except to
ensure that it's syntactically valid, and maybe compose
it with a relative URI here and there.  The last two
are purely syntactic operations.  Do two different URIs
refer to the same resource?  Who cares?  It's not important.

Or you can follow the RDF camp, and treat them as opaque
identifiers that can be compared for equality, again
a purely syntactic operation.  Do two different URIs
denote the same resource?  Only if there's an assertion
somewhere that says they do.  Otherwise, who cares?  It's
not important.

Or you can follow the xml-dev approach, and continue
to spend time and energy trying to figure out how many
angels can dance on the head of a pin, and whether they're
really dancing on the same pin or not.



--Joe English

  jenglish@f...

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.