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

On Fri, 22 Feb 2002, Jonathan Borden wrote:

> 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).

"with identity" was always pretty wooly, but yes; basically resources are
just _things_.

> 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.

RFC2396 doesn't have a monopoly on resource identification; there will be
many other ways of identifying those self-same resources (eg. through
identifying descriptions, in RDF or other languages).  It just so happens
that URIs provide a common convention for identifying/naming resources.
Confusingly enough, we now realise that URI-references (as well as plain
URIs) can also identify resources. RFC2396 doesn't spell this out, but it
doesn't rule it out either.

>
> 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.

Interesting trick, but I believe an unecessary one. We don't need to
introduce a new class of things ('subresources') alongside our existing
'resource', since 'resource' as a category already includes all those
things you're calling 'subresources'. Unless you're proposing that
subresource and resource are disjoint, which would be rather confusing.


> 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).

If we take the view that 2396 only gives us part of the picture, we can I
think come to the view that URI references and URIs both name resources.

Maybe we could tweak your notion of 'subresource' and use it as relation between
pairs of resources whose identifiers are URIs and URI-refs respectively,
(eg. http://foo and http://foo#bar) rather than as a sub-category of the
class 'resource'. Actually I don't think even that'd be quite right; the
'subresource' relation is really about the names (ie. the URIs and
URI-refs) of resources, and only indirectly about the resources themselves.

All of which reminds me that I'd find RDF's use of URIs simpler if the
URI node labels were reflected more explicitly into the graph as
properties, rather than being baked right into the core...

> 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!).

Dan

>
> 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 Saturday, 23 February 2002 12:04:45 UTC