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

Hi Tim,

Thank you for initiating this discussion.  I'm sorry I missed it earlier; I 
try to monitor the TAG traffic, but there is quite a lot; I'm sure you know 
the problem.

If you will forgive me making a process suggestion, when the TAG wishes to 
stimulate discussion on a topic which is known to affect/be of interest to 
specific WG's, would it be a good idea to contact the WG directly.

I have sent a pointer to this message to the RDFCore WG, so they know now.

Anyway to more substantive matters:

At 06:03 10/05/2002 -0700, Tim Bray wrote:
>>Raised by: Jonathan Borden
>>   http://lists.w3.org/Archives/Public/www-tag/2002Jan/0178
>>Raised date: 22 Jan 2002
>>Accepted by TAG 28 Jan 2002:
>>   http://www.w3.org/2002/01/28-tag-irc

As background information, RDFCore had an issue:

   http://www.w3.org/2000/03/rdf-tracking/#rdfms-qname-uri-mapping

which was raised by Jonathan.  RDFCore decided not to change its current 
algorithm for computing a URI form a qname; the resolution is documented at 
the URL just given.

My interpretation of this decision is that the WG felt that, considering 
just the needs and effects of RDF alone, there was insufficient reason to 
justify a change to the existing specification.

The tag, with a broader viewpoint, may come to a different conclusion.  If 
it does so, I would hope that the RDF community would move quickly to 
support it.

The essence of Jonathon's issue seems to be encapsulated in:

[[
The problem is that
XML Schema identifies types by QName, and unless there is a reasonable
translation between QNames and URIs, RDF is likely to become more broken
with time.
]]

and our understanding of what is a "reasonable" algorithm for translating 
between URI's and qnames.

I suggest that an early step in pursuing this issue should be the 
production of a test case which demonstrates the unreasonableness of the 
algorithm used by RDF.


>I have an action item to get some www-tag discourse going on this one.
>
>Per the Namespaces REC, a qname can be seen as a two-tuple: namespace 
>name, local name.  The namespace name is a URI reference.
>
>In RDF, there is an explicit mechanism for turning these into URIs: 
>concatenate the namespace name and the local name.  For this reason, 
>namespaces for RDF applications often end in '#' or '/'.

I think there are really two reasons why writers of RDF schemas often end 
their namespaces in these characters.

   1) RDF has a syntactic shortcut which encourages the use of names of the 
form
        name-space-uri#name for URI's of classes and properties

   2) If the namespace URI ref ends in a character which cannot appear in the
      localname part of a qname, then a commonly used algorithm can determine
      the namespace from the URI alone.  The use of this is not mandatory, as
      RDF defines another means of associating a namespace with a URI.

In response to another similar issue:

   http://www.w3.org/2000/03/rdf-tracking/#rdfms-uri-substructure

RDFCore has recommended that writers of RDF schemas should end their 
namespace URI's in '/' or '#' characters.


>Qnames work effectively as universally-unique labels in markup 
>applications.  Given that the Web has as one of its bases the notion of 
>the universal flat URI namespace, it would seem desirable to express a 
>qname as a URI, as is done in RDF.  That is to say, given any element type 
>(in the XML 1.0 sense) that was a qname, it would have its own URI that 
>you could use to talk about it and potentially retrieve information about it.
>
>It wouldn't be that hard to write a simple rule for mapping qnames to 
>URIs.  A little thought shows that it the mapping would have to be reversible,

It would be helpful if you were to document the argument that leads to the 
conclusion that the mapping must be reversible.  RDFCore has decided that 
it prefers to accept the current non-reversible mapping in preference to 
breaking existing RDF.  I take it your argument would be based on uses 
other than RDF.

>  which adds to the difficulty, but is certainly not insuperable.  It 
> might not be possible to be entirely compatible with the way RDF 1.0 has 
> done this, but perhaps it's not too late to fix RDF.

Given good reason, I wouldn't have thought so; in fact the sooner the better.


>So the first-level questions to address are:
>
>- is this a good thing to do?
>- how important is it, relative to all the other things the W3C needs to 
>worry about?
>
>There's a meta-question that goes along with these.  If every qname 
>becomes a URI, the question arises of what the URI addresses.

That feels a bit like inventing a problem.  I suggest that unless the TAG 
has identified a compelling reason to answer this new question, it can be 
safely left until someone raises it.  RDFCore is trying to get to last 
call, and a quick decision on the qname/uri mapping question is highly 
desirable.

>   These would be useful, just as namespaces are useful, even in the 
> absence of a resource representation to be obtained by dereferencing.  On 
> the other hand history shows that people expect URIs to be dereferencable 
> and are confused when they're not.  RDDL (http://www.rddl.org) is an 
> example that shows the kind of thing you might want to get by 
> dereferencing this kind of namespace URI).  Assuming that it's a good 
> idea to map qnames to URIs, is it necessary at the same time to solve the 
> issue of what they should point at (which BTW is TAG issue #8).

No.

Brian

Received on Wednesday, 22 May 2002 13:53:28 UTC