RE: Q to implementers: Resource identifiers - XML Names and/or(concatenated) URIs? (was RE: rdfs.isDefinedBy...)

> No. I meant exactly what I said.

Good... I was just making sure that your comment was specifically in the
context of RDF.

> RDF, quite frankly, is very poorly behaved with regards to its use
> of qnames. It disregards much of what is expected of qnames.

Yes.

RDF would have been much better served by having a concept of "identity" not
specific to URIs, with a base set of (and RDF representations for) supported
types of identity, URIs being one and QNames the other. Perhaps XPointer
could later join the list, as some have suggested.

IMHO, there is and will continue to be far more identifiable information on
the web that is not identified by just a URI, or for which the provider does
not wish to grant and retain a URI. There will also be far more potentially
usable schema information which is identified by non-URI identifiers.

As an example, there are far too many XML element names out there begging to
become the objects of rdf:type statements. There are far too many XML
attribute names out there begging to become the predicates in countless
statements. There is just far too much usable XML out there to ignore, both
as input to and output from RDF applications.

The problem isn't just that RDF doesn't actively support this vast pool of
information. It's worse - RDF actively and consciously excludes it by
denying its concept of identity.

We need integration-friendly (low barrier to entry, safe round-tripping,
etc.) ways to represent these identities consistently across applications.

A blunt statement must be made (Patrick, please understand that I don't
consider you a target of this statement): Many of us need these mechanisms
now. Those wearing blinders aren't helping RDF.

Those without such requirements can obviously make due with RDF as it
stands. However, many of us have such requirements and want to satisfy them
as consistently with the spec and other applications as possible. As such,
we come to this mailing list to state our position, detail our needs, and
attempt to work out solutions acceptable to people with all kinds of
requirements. It is, after all, in everyone's best interest that our systems
integrate with theirs, even if they don't have the same requirement for, in
this example, "XML-friendliness". The response from those without such
requirements is, well, less than constructive in most cases.

Patrick, you have been better than most - willing to agree on the issues and
discuss them even if your requirements and your position on solutions differ
from ours. Others have been less willing, and make an unfortunate statement
about the community:

Those of us with such requirements are here to find agreeable solutions,
those without such requirements seem, for the most part, to want only to
insult and/or ignore such requirements and those who express them. My
requirements are not invalidated by the fact that others don't share them.

Perhaps now people might understand why I requested, at the very start of
this thread, to restrict the discussion to implementable solutions.
Unfortunately, this thread has long-since shifted into well-covered
territory we all know can't reach consensus. Herein lies a key point - I
didn't come here expecting consensus on the core issues, I came here seeking
solutions agreeable to those who have long-since agreed to disagree on them
(the core issues). I am, admittedly and sadly, less hopeful now.

At the end of the day, if no solution can be found to be agreeable, those
with such requirements will still be faced with satisfying them, and satisfy
them they will. Whether or not the community is involved in defining the
solution is entirely up to it's members.

> <soapbox>
> We will never be able to fully reconcile qnames and URIs, nor
> should we even bother to try. All we need to do is respect the
> full structure and semantics of qnames in our RDF/XML
> serialization, and only use URIs in such serializations to
> denote resources.
> </soapbox>

While I can certainly understand how you might reach such a position, I have
to disagree with it. If you want RDF applications to only ever integrate
with, benefit from, and provide benefit to other RDF applications, then by
all means your soapbox position is workable. On the other hand, if you want
widespread adoption of RDF on the internet at large you're going to need to
leverage existing investments in XML and other web technologies. RDF is not
capable of doing this without mechanisms that can consistently rationalize
more of the internet's identifiers.

Jeremy Gray

Received on Wednesday, 12 June 2002 12:42:14 UTC