- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Sat, 23 Feb 2002 13:36:45 -0500
- To: "Dan Brickley" <danbri@w3.org>
- Cc: "me" <me@aaronsw.com>, "Pat Hayes" <phayes@ai.uwf.edu>, "www-rdf-comments" <www-rdf-comments@w3.org>
Dan Brickley wrote: > On Fri, 22 Feb 2002, Jonathan Borden wrote: ... > > > 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. > > So could we take your approach, but do away with the new notion of > 'subresource' that it introduces? Or do you claim that each 'subresource' > can never have a plain URI name? (if so, this gets us into the murky > territory of accounting for how naming works, and who can assign names > to what... let's not go there!). > Yes. There is no need for the RDF community to concern itself with "subresources". That is to say, the notion of "subresource" is encompased by the RDF usage of the term "resource". I am thinking that the term "subresource" is itself misleading, and strongly considering releasing an update, replacing the term "subresource" with the term "node", and RDF would be just as good to replace "resource" with "node" or "thing" (ala DAML). i.e. I have no strong reason to believe that the RDF relationship (if any) between: http://example.org/Unicorn and http://example.org/Unicorn#LeftButtock is any different than the relationship between http://example.org/Unicorn and http://example.org/Unicorn/LeftButtock For example the an RDF document might assert the first URI to denote a "Unicorn" and the second (in either case) to denote "Pat Hayes' Home Page" which is to say that we treat URIreferences as opaque identifiers. Perhaps RDF might say something along the lines: "The names of things are created according to the syntax of URI references [RFC2396]." Or, if there is a strong desire to use the "resource" term: something like "RDF's use of the term 'resource' differs from RFC 2396." Jonathan
Received on Saturday, 23 February 2002 13:48:45 UTC