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

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

From: Sean B. Palmer <sean@mysterylights.com>
Date: Wed, 6 Jun 2001 17:19:54 +0100
Message-ID: <01e301c0eea4$afca6ca0$60dd93c3@z5n9x1>
To: <Patrick.Stickler@nokia.com>, <www-rdf-interest@w3.org>
Cc: <Ora.Lassila@nokia.com>
> But if two different schema encodings are used to reify the same
> concepts, belonging to the same conceptual namespace, but which have
> different URI fragment syntaxes, then the same RDF statements which
> are valid according to one schema encoding are not valid according
> to the other.

What do you mean by different fragment syntaxes? Let's take XSD once
again as the example:-


This is the namespace that you use in all applications which do not
concatenate names onto the end of the URI, but merely recognize the
names as somehow belonging to the namespace as a name. For example,
all XSD processors use this namespace.


This is the namespace that you *could* use as an alias so as to form a
QName that resolves to a URI that is explicitly set out in the XSD
specification as being the intended URI reference for any of the XML
Schema datatypes. As DanC pointed out to me, if you were using the
following datatype in an RDF application:-


Any of the following would be O.K.:-

   @prefix a: <http://www.w3.org/2001/XMLSchema#> .
   @prefix b: <http://www.w3.org/2001/XMLSchema#i> .
   @prefix c: <http://www.w3.org/2001/XMLSchema#in> .

   a:int :name "int" .
   b:nt :name "int" .
   c:t :name "int" .

An XSD processor wouldn't be expected to process this, because,
obviously, it's RDF. Also, and RDF processor wouldn't be expected to
process an XSD file using the namespace without the hash, so there is
no conflict.

The only conflict arises when there are no standard URI References set
out in a specification. This is a problem with, for example, XHTML.

Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Wednesday, 6 June 2001 12:19:35 UTC

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