W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2002

Re: Documented MIME-type dependency of fragment identifiers

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Mon, 08 Jul 2002 11:21:58 +0100
Message-Id: <5.1.0.14.2.20020708105556.03986870@joy.songbird.com>
To: Frank Manola <fmanola@mitre.org>
Cc: RDF core WG <w3c-rdfcore-wg@w3.org>

At 05:54 PM 7/5/02 -0400, Frank Manola wrote:

>Graham Klyne wrote:
>
>>During a recent informal telephone discussion, I was asked to post 
>>references to documentation indicating that the interpretation of 
>>fragment identifiers on URIs, in normal web use, is considered to be 
>>dependent on the MIME content-type of the resource representation obtained.

[...]

>... but it seems to me that any resolution of this issue in RDF Core WG 
>text (normative or non-normative) needs to
>
>(a) take the above general "intuition" about what fragment ids seem to 
>mean more to heart, and deal with it explicitly, rather than talking about 
>MIME type dependencies and RFC2396 without further elaboration, and

Fair point.  That suggests to me an introductory paragraph (in my section 
6.3) that is more explicit about browsing behaviour and RDF denotation.

Off the cuff ...
[[
In the following discussion, a URI means an absolute URI without a fragment 
identifier, and a URI reference means a URI with an optional fragment 
identifier.

In the Web, URI references have most commonly been used for creating 
hyperlinks in a global information space.  In this use, the URI part of a 
URI reference is taken to address a resource for which one or more 
representations can be retrieved, using retrieval mechanisms that are 
well-known to the browsing software (most commonly, the HTTP 
protocol).  Normal web browsing depends on this ability to retrieve 
resource representations.  This is what is meant below by "normal web use".
[[[Consider change of terminology to "normal web browsing"?]]]

URI references can also be used as resource identifiers, in applications 
whose normal operation does not depend on retrieval of a resource 
representation.  XML namespaces and RDF are two such applications.  The 
following discussion addresses the clearly desirable goal that URI 
references used in RDF should be interpreted in a fashion that is 
compatible with normal web browsing.

In particular, normal web browsing uses fragment identifiers in a way that 
depends on the MIME content-type of a retrieved resource representation 
[[[references]]].  RDF, on the other hand, treats a URI reference as an 
opaque identifier that denotes some specific value, without requiring that 
the URI part be dereferencable.
]]

Does that touch the right points?  I feel it is too long, but I can 
wordsmith down when I better understood what needs to be said.

>(b) in particular, deal explicitly with how our current understanding of 
>fragment ids (and the complications thereof) relates to the description 
>cited above from the original M&S text.

I'm not sure what is "our current understanding" here ... that's one of the 
reasons I felt the section 6.3 material needed drafting, particularly since 
it represents a relatively recent understanding on my part.

>I have a vague notion that the material in section 6.3 of your overview 
>document could be a basis for doing this, but I think some wordsmithing 
>and additional detail about the RDF "fragments" or "views" would be 
>appropriate.

OK ... I'll think about that (see above).  Thanks for the feedback.

#g
--

(Leaving this for convenience of reference to the background URIs...)

>>I'll also remind you of the words I have suggested for reconciling RDF's 
>>use of URIrefs (with fragment identifiers) with this current Web usage:
>>
>>http://www.ninebynine.org/wip/RDF-basics/2002-06-27/Overview.htm#xtocid103660 
>>
>>Finally, I note that the current TAG discussion of this issue is taking 
>>place in a slightly different context, namely the use of HTTP URIs:
>>   http://www.w3.org/2001/tag/ilist#httpRange-14
>
>-------------------
>Graham Klyne
><GK@NineByNine.org>
Received on Monday, 8 July 2002 06:58:01 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:49:49 EDT