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

>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 Thursday, 21 February 2002 19:38:38 UTC