W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2001

RE: What to do about namespace derived URI refs... (long)

From: Larry Masinter <LMM@acm.org>
Date: Wed, 6 Jun 2001 17:08:29 -0700
To: <www-rdf-interest@w3.org>
>    http://robustat.net/set.rdf#Truth
> That's an RDF document, with a FragID of "#Truth" after it. As such,
> you can't browse it conventionally as you would HTML, and it contains
> data, not documentation. By adding ID="Truth" your browser won't go to
> that FragID. Hence, you can use that to identify your concept of
> "Truth", and it won't conflict with any bookmarking programs, because
> no one is going to bookmark it - they can't even conventionally access
> it.

I don't think this is a good idea; it's not how fragment identifiers
are used, it ties the level of meaning to the MIME type being used
to represent meaning, it ignores the fact that HTTP content negotiation
can deliver different MIME types for the same URL. Since the application
of fragment identifiers is defined to relate to the MIME type of the
retrieved entity, it requires a processing model that has you go
off and perform some http access in order to decide whether
"#Truth" does or doesn't occur as an ID inside whatever XML
you get inside http://robustat.net/set.rdf. You assert 
"That's an RDF document", but there's nothing that requires it
to always be an RDF document no matter what (if you only
Accept: text/html, the server *should* try to translate your
rdf into HTML). And even if it is always an RDF document expressed
in XML, adding ID="Truth" to the XML would mandate that
your browser SHOULD go to the ID and select it.

See discussion around:


# The use of URIs in RDF and as XML namespace names to identify
# things other than network resources is a bit of semantic extension
# that doesn't work all that well. 



(especially the idea of 'ttdb:<url>' as a URL that identifies
"the thing described by" to give you the level of indirection
you want.

Received on Wednesday, 6 June 2001 20:09:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:36 UTC