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

RE: What to do about namespace derived URI refs...

From: <Patrick.Stickler@nokia.com>
Date: Thu, 7 Jun 2001 12:18:43 +0300
Message-ID: <6D1A8E7871B9D211B3B00008C7490AA50795873D@treis03nok>
To: champin@bat710.univ-lyon1.fr, LMM@acm.org
Cc: www-rdf-interest@w3.org

> -----Original Message-----
> From: ext Pierre-Antoine CHAMPIN [mailto:champin@bat710.univ-lyon1.fr]
> Sent: 07 June, 2001 11:20
> To: Larry Masinter
> Cc: www-rdf-interest@w3.org
> Subject: RE: What to do about namespace derived URI refs...
> On 06 Jun 2001 17:08:29 -0700, Larry Masinter wrote:
> > http://lists.w3.org/Archives/Public/www-rdf-logic/2001May/0289.html
> > 
> > (especially the idea of 'ttdb:<url>' as a URL that identifies
> > "the thing described by" to give you the level of indirection
> > you want.
> Interesting.
> Another idea, as Jonathan Borden proposed, would be to have a
> mime-type-independant fragment syntax... Like
>   http://mydomain.org/mydoc#the_thing_called(Truth)
> or at least, a way of constraining the mime type a given 
> fragment is to
> be used with
>   http://mydomain.org/mydoc#(type=text/rdf)Truth
> Just ideas...
>   Pierre-Antoine

Or how about simply URNs for abstract resources and URLs for
concrete resources, with fragment syntax dictated by the MIME
content type of the concrete resource (with all the limitations
inherent therein)?

Why must we use URLs or URL refs to reify abstract concepts?!

Yes, yes, "URN" and "URL" are really interpretations of a URI for a given
context/environment in that e.g. if a resolution agent for a URN exists
and can resolve it to a MIME content stream, then it is a URL, but
being able to resolve a URN to a content stream neither is required
nor does it dictate the syntax of the URN; which is the crux of
the problem, as I see it.

But even though a given URI scheme might be a URN or URL depending
on context, if it is ever a URN, then it is understood that it might
never resolve to actual content -- whereas the HTTP URI scheme is
by definition expected to resolve to content; and thus is always
a URL. If folks want to use HTTP URIs as URN's, then let's change
the definition and associated semantics of the HTTP URI scheme, eh?

Just because we *can* do something, does not mean that we should... so
let's stop using HTTP URLs and URL refs as URNs and figure out how
to define a consistent, explicit, and standardized URN scheme for
universal identifiers (or adopt an existing one and support it, if
such exists).


Received on Thursday, 7 June 2001 05:18:50 UTC

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