- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Fri, 22 Feb 2002 07:58:14 -0500
- To: <me@aaronsw.com>, "Pat Hayes" <phayes@ai.uwf.edu>
- Cc: <www-rdf-comments@w3.org>
Pat, 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. Jonathan > >Apropos the discussion of URI vs. URIviews: > > > >Clearly the RDF community intends to identify <rdf:resource>s by URI > >references. > > > >On the other hand RFC 2396 identifies <rfc2396:resource>s by URIs. > > The critical point to note is that these two senses of 'identify' are > different. The RDF sense is 'denote' or 'refer to'; the RFC 2396 > ......well, the fact is that RFC 2396 is ambiguous and almost > incoherent, but the sense that is relevant to this discussion is that > it means something like 'identify well enough to locate and retrieve > using a transfer protocol'. > > >The > >status of what a fragment identifier identifies is a bit unclear from the > >documents and practice. We have submitted an internet draft which attempts > >to clarify this. > > > >http://www.ietf.org/internet-drafts/draft-borden-frag-00.txt > > > >This is an early draft, and needs to be cleaned up a bit but is presented > >for discussion. > > > >To summarize: > > > >On the HTML/HTTP web, a URI reference is resolved to a fragment of a > >document by the following process: > > > >1. URI part sent to HTTP server > >2. HTTP server maps _resource_ identified by URI onto document > >representation which is called an _entity_ > >3. Entity returned to client. > >4. Client parses entity, and uses fragment identifier to obtain piece of > >document for display. > > > >In this usage, which is straightforward, a given fragment identifer e.g. > >#toc is interpreted according to the rules of the returned media type > >text/html directing the browser to display the table of contents. > > > >RDF, however, uses URIreferences as opaque identifiers for resources and > >this identification is outside any HTTP transaction -- hence no media type > >applies. > > This is what Aaron said on the RDF core WG discussion of this > recently. But this seems to me to be confused. RDF 'uses' them in > this way in the sense that the RDF semantics places no restrictions > on the RDF *interpretation* of a uriref. But that sense is irrelevant > to any other processes that make up the computational fabric of the > web, such as transfer protocols. I'm sure there are RDF urirefs > which refer to me, but I would be most upset if any kind of web were > to tug my sleeve or call my name when someone clicked on one of them. > > If we stick to the domain of computable operations on RDF documents, > then RDF's use of fragment ids is quite well-defined and limited: it > uses them to identify *syntactic parts of RDF documents* (typically, > referring IDs located inside RDF assertions inside RDF documents > which have an absolute URI.) So as far as all questions concerning > transfer protocols are concerned, RDF can be considered to *be* a > media type, since at this level of discussion we are talking about > RDF *syntax*, not RDF semantics. Most RDF semantics isn't even > located on the web, in general. > > >The issue is that without a media type, there is nothing to define > >the syntax of a fragment identifier, or what it might identify. > > Well, as long as RDF knows what it identifies, isn't that enough? > Cf. your HTML/HTTP sketch, above: that seems to work for RDF in just > the same way. The URI is used to retrieve an RDF ontology - a > document - and the RDF client uses the fragId to identify the term > used in that ontology. It is all to do with enabling RDF engines to > make syntactic connections between names, and to retrieve the RDF > syntactic assertions made by one ontology using that name, for use by > another ontology. As far as web transfer protocols go, it works > exactly like the HTML case. > > > > >See: > >http://www.ietf.org/internet-drafts/draft-borden-frag-00.txt > > > >A generic fragment identifier syntax is defined which encapsulates known > >fragment identifier syntaxes: > > > >The term "sub resource" is introduced, to define what a URI reference > >identifies. > > That is meaningless in general, however. Anything can be a resource. > What is a "subresource" of, say, a unicorn or a galaxy? You seem (?) > to be confusing a URL sense of 'resource' meaning: part of a > retrievable web document, with an RDF/URI sense of 'resource' > meaning: entity referred to by an RDF name. (This is the familiar > use/mention confusion that seems to resurface in these discussions > about every six weeks.) The resources that RDF *refers* to are, > typically, not the kind of things that can possibly live on any web > or be transferred by any kind of transfer protocol. The resources > that RDF *uses* are pieces of syntax - ultimately, character strings, > in effect - that can be easily considered to be a mime type or a > media type without straining these concepts unduly. RDF *documents* > have parts that are identified by (not referred to by) urirefs with > fragments. Those are the only things that we need to be concerned > with here. What RDF interprets them to *mean* is a matter which is > internal to RDF, just as the operational significance of a fragID > locating a place in a jpeg image might be a private matter to > Fireworks. > > Pat > > -- > --------------------------------------------------------------------- > IHMC (850)434 8903 home > 40 South Alcaniz St. (850)202 4416 office > Pensacola, FL 32501 (850)202 4440 fax > phayes@ai.uwf.edu > http://www.coginst.uwf.edu/~phayes > >
Received on Friday, 22 February 2002 08:00:52 UTC