RE: updated: RDF/XML Media Type registration draft

> There is a basic problem here, one that has been surfacing in the 
> discussions on the TAG group. URIs are supposed to denote things, and 
> also to indicate representations. These are different tasks. If URIs 
> with fragIDs are required to denote structural fragments of RDF/XML 
> documents, then RDF is made impossible; there is then no way to use a 
> URI to denote anything other than a part of a document.

Well, you could use urn:tdb, since there is no 'representation' in that
case. (http://larry.masinter.net/duri.html). Or you could add a separate
RDF operator or change to the RDF syntax that would explicitly indicate
the RDF relation was about the representation or the thing described
by it. 
 
> >  I think it's inconsistent,
> >and leaves you no way to talk about structural fragments.
> 
> But why would anyone want to talk about structural fragments of 
> RDF/XML documents in RDF? The idea is marginally crazy; but if 
> someone really wanted to do this, the appropriate technique to use 
> would surely be reification.

What do you mean 'in RDF', though? The interpretation of
fragment identifiers shouldn't depend on the context of
use of the URI reference. And surely there are cases where
it makes perfect sense to talk about structural fragments of
RDF/XML documents.

> >
> >The notion that the resource identified by
> >"http://some.host/some.path#" and "http://some.host/some.path"
> >are completely unrelated seems pathological.
> 
> They are related, but not by any kind of structural relationship: 
> they are related by denotation. The URI without the fragID represents 
> an RDF/XML document, which is a representation which contains 
> assertions which *use* the URIref with the fragID to *refer to* 
> entities. So they are the entities referred to in the document; and 
> the use of the URI+fragID outside the document ensures that other 
> documents can refer to the same entities. What other convention could 
> *possibly* be used to ensure this?

I was reacting to the statement that they were 'completely
unrelated'. 


> >So not sure 'attention is recommended' captures
> >the necessary caution.
> >
> >I think part of the problem is that the draft only
> >addresses URI references with fragment identifiers
> >when those URI references are used _as RDF terms_.
> >But what about other uses? If I have a web page with
> >
> ><a href="http://some.host/some.path#concept">link
> >to a concept</a>
> >
> >what might a legitimate response be to clicking
> >on that as a link? I can't tell from this document
> >or the documents it references.
> 
> Why would RDF need to specify this? RDF is not intended for 
> responding to clickings on URIrefs. HTML does not specify what 
> URIrefs denote, either. They live in different worlds.

It should be the responsibility of the definition of
a MIME type to describe how fragment identifiers work
with that MIME type, independent of the context of
the URI reference that contains the fragment identifier.

HTML _does_ specify what URI references mean...
RFC 2854 (the 'text/html' Media Type) section 3.
http://www.zvon.org/tmRFC/RFC2854/Output/chapter3.html
for example).

Received on Wednesday, 3 September 2003 01:59:43 UTC