Resource references/httpRange-14 (was: [Minutes] 1 July TAG teleconf)

With reference to:

At 06:45 PM 7/1/02 -0400, Ian B. Jacobs wrote:
>      Disagreement over "According to [RFC2396] a
>      resource is "anything that has identity." A
>      resource is part of the Web when there is a URI
>      that identifies it."
>      TBL: Should be URI Reference. Otherwise you
>      can't refer to some resources.
>      RF: We are digging a hole for ourselves by
>      saying that abs URis with frag ids define a new
>      space.
>      RF: URIs point to resources; frag ids are
>      client-side indirect references.
>      TBL: In RDF, there's another indirection - the
>      frag id is not part of a resource but is about
>      the thing described by the RDF. I have said many
>      times that the phrase "fragment identifier" is a
>      mistake. The meaning is completely
>      language-dependent.
>      IJ: Are there two self-consistent models here?
>      Which one has advantages?
>      TBL: Yes, I think you could produce two
>      consistent models.
>      SW: Seem to be two concepts - identification
>      (speak about it) and dereferencing (get it). Are
>      we conflating those two notions? Would ad-hoc
>      time on the phone help?

I don't know if this is helpful, but there are some words I've suggested 
for use with RDF (adapted from discussion on www-talk):

[[
How should RDF treat a URI reference with a fragment identifier? 
Conventional web architecture has that the meaning of a fragment identifier 
is dependent on the MIME type of a resource that is obtained by 
dereferencing the URI part. URIs without fragment identifiers are generally 
presumed to map to some resource for which a Web representation (or 
several) can be retrieved. But RDF has no concept of a fragment identifier 
separate from a URI: RDF treats a URI reference as an opaque identifier 
that denotes some resource [RDF-SEMANTICS]. Further, an RDF resource 
identifier may denote something that is not web-retrievable; e.g. a car, or 
a Unicorn.

These apparently conflicting interpretations can be reconciled if:

- we assume that the URI part (i.e. excluding fragment identifier) of any 
URI reference used in an RDF document indicates a Web resource with an RDF 
representation. (If it is not dereferencable as such on the web, so be it, 
but we must assume its notional existence.) So when someurl#frag is used in 
an RDF document, someurl is presumed to designate an RDF document.

- when used in an rdf document, someurl#frag means the thing that is 
indicated, according to the rules of the application/rdf+xml mime type as a 
"fragment" or "view" of the RDF document at someurl. If the document 
doesn't exist, or can't be retrieved, then exactly what that view may be is 
somewhat undetermined, but that doesn't stop us from using RDF to say 
things about it.

- the RDF interpretation of a fragment identifier allows it to indicate a 
thing that is entirely external to the document, or even to the "shared 
information space" known as the Web. That is, it can be an abstract idea, 
like my car or a mythical Unicorn.

- thus, an RDF document acts as an intermediary between some web 
retrievable documents (itself, at least, also any other web-retrievable 
URIs that it may use, including schema URIs and references to other RDF 
documents), and some set of abstract or non-Web entities that the RDF may 
describe.

This provides a handling of URI references and their denotation that is 
consistent with the RDF model theory and usage, and also with conventional 
web axioms. This approach somewhat extends the idea of a "fragment" or 
"view" beyond the common idea (when handling web documents) that it is a 
physical part of a containing document.

In view of this, it is reasonable to consider that URIs without fragment 
identifiers are most helpfully used for indicating web-retrievable 
resources (when used in RDF), and URIs with fragment identifiers are used 
for abstract ideas that don't have a direct web representation. This is not 
a hard-and-fast distinction, as the line between resources having or not 
having a web-retrievable representation is sometimes hard to draw precisely.
]]

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 2 July 2002 09:58:53 UTC