RE: Dedicated, Standardized URI Scheme for QNames?

Sorry, I see no significant difference between your:

> <http://www.w3.org/1999/xhtml#title>
>    a :ExpEName;
>    :namespace <http://www.w3.org/1999/xhtml>;
>    :name "title" .

and

  <qn:title:http://www.w3.org/1999/xhtml>
     a :ExpEName;
     :namespace <http://www.w3.org/1999/xhtml>;
     :name "title" .

Both simply make statements about a URI (or are those
statements about the resource identified by the URI? ;-)

Except that in the latter case, using the qn URI scheme:

a) the URI is derivable without chance of collision

b) the last two properties are redundant

I.e., the following accomplishes the same, but in a more
compact form:

  <qn:title:http://www.w3.org/1999/xhtml>
     a :ExpEName .

Since you *have* to define the contextual distinction of
element QName versus attribute QName, etc. explicitly in the
RDF, I see no reason why it is the qn URI that has a problem.
It offers no more nor less information in that regard than
the directly concatenated URI.

No?

> > Explicit, yes. Logical, yes. Useful, probably. Simple(r),
> > no. IMO.
> 
> It will be, once you add namespace partitions to your scheme :-)

Just did. See last example above. As you demonstrate so well,
the namespace partitions need not be part of the URI scheme itself,
but can be defined in RDF using your proposed namespace partition
ontology. Great. It compliments either of my proposals nicely.

I don't see how namespace partitions belong in the URI scheme, since
the URI scheme only defines *QNames* not how they are used in any
given model or instance. 

As far as I can tell, all you are doing is taking the existing
(broken) mapping function and making statements about the derived
URI. But the fact that you can get collisions means that your
extra statements about namespace partitions further exacerbates
the problem (if we are not guarunteed unique URIs from QNames). 

E.g.

the elements

  <foo:def xmlns:foo="urn:x:abc">
  <bar:ef xmlns:bar="urn:x:abcd">

gives us

  <urn:x:abcdef>
     a :ExpEName;
     :namespace <urn:x:abc>;
     :name "def" .

  <urn:x:abcdef>
     a :ExpEName;
     :namespace <urn:x:abcd>;
     :name "ef" .
  
Oops! Not only have we gotten a collision between resource URIs, but now
we have conflicting statements about what the names and namespaces
of the single ambiguous URI are! And one QName could have even been used 
for an element and the other for an attribute, further increasing
the ambiguity.

Don't misunderstand me here. It's great if we can model ns partition
information in RDF so that it can be used productively by applications,
but adding the extra information on top of potentially collisive URIs
is just pouring DAMn OIL on the fire (sorry for the very bad pun ;-)

> [...]
> > > The fact that you can't serialize certain URIs is a
> > > separate problem (not fixed by your URI scheme proposal),
> >
> > No? I thought both of my proposals fixed that problem.
> 
> Well, declaring eqivalences is hardly a "new" solution!

I never said it was new. I just said it works (in response to your
saying it didn't work). And if it's not a new solution, and has been 
suggested before (possibly numerous times) then perhaps there's 
something inherently valid in the approach. 

> [...]
> > > and will hopefully be solved in future version(s) of RDF,
> >
> > But if it isn't solved in a near-future version of RDF, there
> > may not be very many distant-future versions of RDF, eh?

> You'll have to ask RDF Core about that.

What? They don't listen to the RDF Interest Group discussions? ;-)

Seriously, though, I intend to do just that...  (but that doesn't mean
that this list isn't the proper forum for such discussions)

Let's be frank here, if RDF cannot ensure the integrity of knowledge
(which it can't with the present mapping function) then we cannot
expect the world to embrace it as the vehicle of the SW. Sorry.

It's a reality of the standards process (or any human endeavor)
that mistakes are made and must be fixed, and particularly with 
standards, fixing mistakes can be quite challenging, as one must
try very hard to not break existing applications based on the 
standard -- but if major mistakes are not corrected, then the future
of that standard will be significantly impacted, and if the correction
causes backwards incompatability, so be it. We are at a point where
such an incompatability is not going to cause too widespread grief
for the RDF community (as that community is still rather small) but
the longer we wait, the more difficult it will be to "do the right
thing".

Folks simply have to admit that RDF serialization was designed with
primarily HTML in mind (and seemingly nothing much more) and as such
has inherited aspects which -- while working fine for HTTP URIs and
HTML fragment syntax, or being familiar to HTML authors -- is not 
sufficiently generic and robust for the full scope which the SW is 
expected to encompass. Fair enough. Every model and standard has a 
historical context, and that context flavors that standard to a certain 
extent. The same is true also of XTM and ISO Topic Maps (though I won't 
open up that discussion here).

But we cannot pretend that the original historical context which gave
birth to RDF is equivalent to the current vision of the SW. It's not.
There's a huge intersection, but they're not equivalent. The SW is not just 
adding metadata to web pages. Even though we *will* be doing that, we need 
to do more, and in fact, I would wager that the majority of metadata and
knowledge in the future SW will not be embedded in web pages, but rather
defined outright as separate RDF instances.

I see RDF being at a crossroads on this specific issue, and which way
it turns (or refuses to turn) will have alot to say about where RDF
will end up. Who knows, maybe XTM will rule the SW...   

Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Tuesday, 21 August 2001 01:23:44 UTC