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

Re: Dedicated, Standardized URI Scheme for QNames?

From: Sean B. Palmer <sean@mysterylights.com>
Date: Mon, 20 Aug 2001 15:47:28 +0100
Message-ID: <008e01c12987$655249e0$2bd993c3@Palmer>
To: <Patrick.Stickler@nokia.com>
Cc: <www-rdf-interest@w3.org>
> > Flaw in the plan: your new URI scheme has no way of
> > representing the difference between element, attribute,
> > and other QNames. So it's useless, QED.
>
> There's a difference?

[[[
In order to support the goal of making both qualified and unqualified names
useful in meeting their intended purpose, we identify the names appearing
in an XML namespace as belonging to one of several disjoint traditional
(i.e. set-structured) namespaces, called namespace partitions.
]]] - http://www.w3.org/TR/1999/REC-xml-names-19990114/

> Explain to me how this difference is presently captured
> in RDF?

It's done by creating some properties and modelling it. It can only ever be
done by creating some properties and modelling it, unless you introduce a
more complete URI scheme that allows for identification of namespace
partitions, which would make the scheme rather unweildy, but technically
sound.

> [...] Does any existing or even percieved XML application
> make use of a difference.

Of course; every XML application that knows about namespaces should know
about namespace partitions. They're simply the things that define "title"
used in an element as being different from "title" being used in an
element. Same names, same namespaces, different resources entirely. They
could mean totally different things.

[...]
> Sorry, I don't see the flaw. Perhaps an example?

There's a huge difference between (both in the XHTML namespace):-

   <title>My Title</title>

and:-

   <span title="My other title">My text</span>

but they both use (in your URI syntax) the same URI:-

   qn:title:http://www.w3.org/1999/xhtml

which isn't good.

[...]
> You then could apply your QName classificatory ontology
> to qn-URIs with no problem, using the explicit qn URI as
> the subject of your statements, and defining which QName
> represented an element, an attribute, etc. Right?

No, that's like having a URI that identifies a duck, but in one document is
labelled as a dog, and in another, a sheep. You have to have separate URIs
for each animal/QName+partition.

[...]
> It may very well be the greatest thing since sliced bread, for
> certain applications, but it does not IMO provide a sufficiently
> concise representation for resource identity.

Seeing as how I've not come across one RDF instance or application that had
either a problem or need to identify a QName...

[...]
> I don't see how it doesn't require anonymous nodes. I guess
> I must be getting lost again in N3 space.

I think you probably are. There's no reason why you *can't* use anonymous
nodes for this, but there's no reason either why you *have* to. For
example:-

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

No anonymous nodes. It does require literals, but they map to data:, URIs
quite nicely, so no problem there.

[...]
> But seriously, I don't see defining the identity of resources
> as anything other than single URIs as being as simple as
> single URIs.

Which is what you get from the above.

> Explicit, yes. Logical, yes. Useful, probably. Simple(r),
> no. IMO.

It will be, once you add namespace partitions to your scheme :-)

[...]
> > 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!

[...]
> > 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.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Monday, 20 August 2001 10:49:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:51 GMT