W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

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

From: Paul Grosso <pgrosso@arbortext.com>
Date: Tue, 02 Jul 2002 09:13:02 -0500
Message-Id: <4.3.2.7.2.20020702090810.027225d8@172.27.10.30>
To: Graham Klyne <GK@ninebynine.org>, www-tag@w3.org

At 14:58 2002 07 02 +0100, Graham Klyne wrote:
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.

But can an application such as RDF redefine the semantic of 
an embedded URI reference in such a way that it predetermines
(overrides) the MIME type of the referenced resource regardless
of how the resource is labeled?

And if it can't, then RDF cannot redefine how to interpret the
fragment identifier; rather, the fragment identifier must be
interpreted according to how the MIME type says it should.

paul
Received on Tuesday, 2 July 2002 10:16:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:09 GMT