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

RE: [rdfmsQnameUriMapping-6] Algorithm for creating a URI from a QName in RDF Model?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 23 May 2002 14:06:50 +0200
To: "Mark Baker" <distobj@acm.org>, "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Brian McBride" <bwm@hplb.hpl.hp.com>, "Tim Bray" <tbray@textuality.com>, <www-tag@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEFKEKAA.julian.reschke@gmx.de>
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Thursday, May 23, 2002 2:03 PM
> To: Julian Reschke
> Cc: Mark Baker; Brian McBride; Tim Bray; www-tag@w3.org
> Subject: Re: [rdfmsQnameUriMapping-6] Algorithm for creating a URI from
> a QName in RDF Model?
>
>
> On Wed, May 22, 2002 at 09:53:11PM +0200, Julian Reschke wrote:
> > So restricting the algorithm to a specific subset of qnames will make it
> > unusable for many specs.
>
> I didn't say that there wouldn't be casualties 8-), only that it was a
> solution usable for multiple URI schema.
>
> > What if the namespace name isn't a URI (but a URI reference like
> > "http://foo/bar#test")?
>
> I believe that a namespace is a resource, not a document fragment, and
> as such, should be identified by a URI, not a URI reference.

Well. The XML namespaces recommendation allows URI references.

> > Proposal:
> >
> > define a new schema like "qn:" and map
> >
> > 	(uriref, name)
> >
> > to something like
> >
> > 	qn:uri-escaped-utf8(name):uri-escaped(uriref)
>
> The enormous cost of deploying new URI schemes has been talked about
> here (and elsewhere) before.  I would recommend that we look for
> solutions that reuse the HTTP scheme, and only consider a new one as a
> last resort.

XML namespace names in URI schemes other than HTTP are very common. So we
need to clarify whether it's a requirement to map those QNames as well. I
think if we don't, this mapping isn't generic, and there's little value in
discussing it here...
Received on Thursday, 23 May 2002 08:07:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:51 UTC