W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2003

Proposed revision to URI fragment text in RDF Concepts (update)

From: Graham Klyne <GK@NineByNine.org>
Date: Mon, 07 Apr 2003 09:09:09 +0100
Message-Id: <5.1.0.14.2.20030407085451.02b7d6e0@127.0.0.1>
To: w3c-rdfcore-wg@w3.org

I received a private comment to my earlier proposal [1] concerning URI 
fragments that indicated some remaining difficulty in understanding the 
intent, in response to which I've drafted a possible small revision to my 
earlier proposal.

[1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0093.html

The differences from the earlier proposal are:

- replace reference to undefined term "web resource" with just "resource".
- replace "interpretation" with "treatment" (of URI fragments) to avoid 
possible confusion with model theoretic interpretation [**]
- indicate earlier that an RDF form of the resource does not need to be 
retrieved.

The revised copy is below.  I've not yet included it in the document.

[[
7. Fragment identifiers

RDF uses an RDF URI Reference, which may include a fragment identifier, as 
a context free identifier for a resource.  RFC 2396 [URI] states that the 
meaning of a fragment identifier depends on the MIME content-type of a 
document, i.e. is context dependent.

These apparently conflicting views are reconciled by considering that a URI 
reference in an RDF graph is treated with respect to the MIME type 
application/rdf+xml [RDF-MIME-TYPE].  Given an RDF URI reference consisting 
of an absolute URI and a fragment identifier, the fragment identifer 
identifies the same thing that it does in an application/rdf+xml 
representation of the resource identified by the absolute URI component.  Thus:

     * we assume that the URI part (i.e. excluding fragment identifier) 
identifies a resource, which is presumed to have an RDF representation. So 
when eg:someurl#frag is used in an RDF document, eg:someurl is taken to 
designate some RDF document (even when no such document can be retrieved).

     * eg:someurl#frag means the thing that is indicated, according to the 
rules of the application/rdf+xml MIME content-type as a "fragment" or 
"view" of the RDF document at eg:someurl.  If the document does not exist, 
or cannot be retrieved, or is available only in formats other than 
application/rdf+xml, then exactly what that view may be is somewhat 
undetermined, but that does not prevent use of RDF to say things about it.

     * the RDF treatment 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 a more general 
idea, like some particular car or a mythical Unicorn.

     * in this way, an application/rdf+xml 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 possibly 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 behavior. Note that nothing here requires that an RDF application be 
able to retrieve any representation of resources identified by the URIs in 
an RDF graph.
]]

#g
--

[**] I think this is illustrative of a general problem we repeatedly 
face:  when trying to support our work with results from a specialized 
domain, we find that words with perfectly intelligible English meanings are 
being hijacked by the more specialized use, which can have the result of 
reducing the range of normal English available for use in the 
non-specialized areas.  This is just an observation;  I don't have a 
general fix to suggest.


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
Received on Monday, 7 April 2003 05:35:36 EDT

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