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: Tue, 09 Jul 2002 21:17:02 +0100
Message-Id: <5.1.0.14.2.20020709204914.038b9890@joy.songbird.com>
To: Frank Manola <fmanola@mitre.org>
Cc: RDF core WG <w3c-rdfcore-wg@w3.org>

At 08:58 AM 7/8/02 -0400, Frank Manola wrote:
>Here's where I think some additional discussion is necessary (I suppose it 
>could go in the Primer).

I'm happy to sort out the content then decide if it needs to go somewhere 
else...

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

Yes, that _was_ my intuition too, but I now think it's not sustainable.

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

OK, good point.  Enlarged text below.

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

Er, I'm not sure I can think of one.

Actually, by "normal behaviour" I did mean just that kind of behaviour that 
one sees when web browsing.

...

Here's my proposed revised text;  the last two paragraphs below are 
expanded from what was previously one paragraph.

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

Normal web browsing uses fragment identifiers in a way that depends on the 
MIME content-type of a retrieved resource representation 
[[[references]]].  Specifically, a fragment identifier refers to some 
particular part, or view, of a resource representation.  A browser uses a 
fragment identifier to select for display some part contained within the 
retrieved data;  how the fragment identifier selects that part depends on 
the MIME type of the data retrieved.  For example, when displaying HTML, a 
fragment identifier '#frag' selects a part indicated by <a name="frag"> in 
the HTML data.

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 
dereferenceable.  So, while we may expect when web browsing that 
'http://example.org/somedoc#frag' refers to some part of the resource 
'http://example.org/somedoc', the semantics of RDF do not allow us to 
assume that 'http://fantasy.org/unicorn#head' used in RDF denotes a part of 
the resource denoted by 'http://fantasy.org/unicorn'.
]]

[[[Note to myself:  "Normal web use" changed to "normal web browsing"]]]

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Friday, 12 July 2002 21:13:37 EDT

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