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

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