W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2002

Re: [URI vs. URIViews] draft-frags-borden-00.txt

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Fri, 22 Feb 2002 17:14:54 -0600
Message-Id: <p05101433b89c80e48528@[]>
To: "Jonathan Borden" <jonathan@openhealth.org>
Cc: <me@aaronsw.com>, <www-rdf-comments@w3.org>
>Perhaps a short note of explanation. Aaron's issue is a valid one, however
>my solution is not to change RDF, rather to submit an Internet Draft to the
>IETF which, if accepted, i.e. becomes an RFC, validates the RDF usage. I am
>doing this in a way that does not interfere with other people's (i.e.
>non-RDF) current use of URI refs.
>In an ideal world I would state that:
>Every URI reference identifies a resource. A resource may be anything with
>identity. (This is the RDF usage).
>The 'problem' is that RFC 2396 states that a _URI_ (i.e. without frag id)
>identifies a resource. It doesn't say that a URI ref identifies a resource.
>Not wishing to _supercede_ RFC 2396, i.e. not wishing to redefine the RFC
>2396 definition of the term _resource_, I invented a new term "subresource"
>which is intended to be just like a resource except that it is identifies by
>a URI + a nonblank fragment identifier.
>The net effect is the same, though I admit this way of defining things is
>more circuitous. On the other hand I can't just go around willy-nilly
>redefining how RFC 2396 works (well that is the theory in any case).
>So what I've said isn't much, the effect is to say: The RDF usage is
>correct, but I am saying it in a way that allows non-RDF folks to continue
>to use RFC 2396 unchanged.

OK, then please bear in mind that my recent long response to you was 
written before I read the above.

I think there are still some serious issues to sort out in this area, 
both within RDF and more generally.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Friday, 22 February 2002 18:14:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:59 UTC