Re: Documented MIME-type dependency of fragment identifiers

Graham--

I think your added material is helpful.  However, I'll indicate below 
where I think some more discussion (rather than less) is needed.

Graham Klyne wrote:

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


Here's where I think some additional discussion is necessary (I suppose 
it could go in the Primer).  In my original response to you, I cited the 
way you yourself had used fragment identifiers to identify specific 
subsections of the documents you were citing, which I think is 
more-or-less consistent with the intuition people have about the way RDF 
  intends to use fragments.  Now, above, you say "normal web browsing 
uses fragment identifiers in a way that depends on the MIME content-type 
of a retrieved resource representation".  This may be the case in some 
sense of "normal", but I doubt if it appears that way to most web users 
(who are mostly retrieving html and text documents).  It would help to 
cite an example in "normal" circumstances in which fragment identifiers 
*don't* eppear to have the effects they have when used with html.  In 
other words, I think we ought to talk in terms of "normal" behavior as 
defining what most people see most of the time;  other behavior may be 
consistent with the specs, but if it's rarely seen, it doesn't become 
"normal" by calling it so.  What we're really trying to say is something 
like "in most usually-seen cases, retrieval behavior involving fragment 
identifiers seems to be sort of consistent with the way RDF wants to use 
fragment identifiers, but in fact the specs allow the retrieval behavior 
to be arbitrarily-different, depending on the MIME type of the resource 
representation.  Because of this (and because, according to the specs, 
servers don't need to know anything about URL fragments, because that 
behavior is dealt with somewhere else), there are potential problems..."


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


You're welcome.


--Frank


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


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Monday, 8 July 2002 08:45:45 UTC