RE: Dedicated, Standardized URI Scheme for QNames?

> -----Original Message-----
> From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> Sent: 20 August, 2001 13:47
> To: Stickler Patrick (NRC/Tampere)
> Cc: www-rdf-interest@w3.org
> Subject: Re: Dedicated, Standardized URI Scheme for QNames?
> 
> 
> >    qn:{name}:{namespace}
> 
> 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? Explain to me how this difference is presently
captured in RDF? Does the XML Namespace spec define a significant
difference? Does any existing or even percieved XML application make use
of a difference. I'm talking here about the QName itself, not how it
is used in an XML instance to name an element, attribute, etc.

And how does direct concatenation of namespace and name differentiate
between its use with an element, attribute, etc.?

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

There is nothing whatsoever in a QName which itself defines what it names.
And any such information about its use must be derived from its context,
no matter how you choose to represent it in the knowledge base.

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?

> And you're making a backwards incompatable change to RDF 
> in - 

Well, I *did* point that fact out myself, and even as the primary
reason for not previously proposing such an approach...   ;-)

> we may
> as well start again with RDF 2.0 in that case anyway!

Perhaps we should. Though I think we need a solution sooner than that.

> I still cannot work out why you refuse to accept that QNames 
> can be pointed
> at in the model. 

I haven't refused to accept it. I acknowledged that it could be
done. I just didn't accept it as a reasonable way to represent
the *primary* identity of resources.

Just becaues you can model something with RDF (and as you point
out, you can model *anything* in RDF) that doesn't mean that such
a model should become a "primitive" mechanism of representation.

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.

> I've shown how this corresponds to the 
> appendix of XML
> Names, I've shown how it causes no backwards incompatable 
> changes to be
> made to RDF, I've shown how it makes all syntax extension suggestions
> totally pointless, and I've shown how it doesn't rely on 
> anything other
> than URIs, and doesn't requre anonymous nodes or literals.

I don't see how it doesn't require anonymous nodes. I guess I must
be getting lost again in N3 space. In any case, the representation
at least constitutes a sub-graph, and resources in RDF are not
identified by sub-graphs, but by URIs. You can define a query template
that is a sub-graph, which may resolve to one or more resources, but
is that really how you want to reference resources as a primary
mechanism?
 
> The simple answer is right under your nose. 

I must then have a really big nose, cause I can't see it ;-)

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

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

> RDF can say anything about
> anything, so it can quite easily cope with as piffling a problem as
> modelling QNames. 

But just because you can model it does not mean that model is sufficiently
constrained and basic as to become a primitive of primary representation for

a broad range of resources.

> 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. They may both
deserve rejection for other reasons, but they still provide a solution
to the mapping problem at issue here.

> 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?

> and 
> alternate syntaxes.

Any alternate syntaxes which are not part of the standard and required
to be supported by all compliant systems will degrade the scope and
interoperability of the SW, and hence are a bad thing (from a global
perspective). Alternate syntaxes defeat the very purpose of having a
standard in the first place.

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 Monday, 20 August 2001 09:27:57 UTC