RE: [Fwd: xmlns, uri+name pairs or just uris..? Clarification n eeded.]

I have been following this thread with great interest and it occurred to me
that all of the suggestions made seem to be no more than kludges to work
around a fundamental flaw in the RDF M & S Recommendation.

I was under the impression that the primary purpose of namespaces is to
prevent XML elements from two separate vocabularies from clashing.  

At the risk of seeming controversial - and getting flamed ;-) - this is how
my thinking goes:

1) the 'http://www.w3.org/1999/02/22-rdf-syntax' &
'http://www.w3.org/TR/rdf-schema-ns' namespaces ensure the uniqueness of all
the element tags and attributes in those two specifications.

2) Any RDF parser is going to know how to treat tags from these vocabularies
implicitly.

3) The mechanism for mapping qnames to URIs is flawed and should be
abandonned because:
   a) different qnames could map to the same resource (see the various
'foobar' examples in a previous message) and they 	shouldn't.
   b) the mapping is not reversible unless certain restrictive idioms are
employed, such as a '#' suffix.
   c) the mapping breaks down for urn namespaces.

4) There is no problem using RDF URI identifiers as attribute values, e.g.
<rdf:Description rdf:type="http://..."/>

5) There are two main places where the qname mapping gets used:
   a) Properties, e.g. <rdf:Description><dc:title
rdf:resource="xyz"/></rdf:Description>
   b) Abbreviations, where 
      <rdf:Description type="http://mydomain/myns#MyType/> 
      becomes
      <myns:MyType xmlns:myns="http://mydomain/myns#"/>
      and 
      <rdf:Description><myns:prop
xmlns:myns="http://mydomain/myns#">xyz</myns:prop></rdf:Description> 
      becomes
      <rdf:Description myns:prop="xyz"/>

Hence the solution could be to begin work immediately on RDF version 2,
where:

1) namespaces are only employed to segregate rdf from other vocabularies -
so there will be no namespace quirks or restrictions associated with RDF2.

2) basic syntax is the only legal syntax:
   a) fixed rdf tag names such as rdf:Description and a new rdf:Property tag
(rdfs must then define those properties like <rdf:Description
type="#PropertyClass">...</rdf:Description>).
   b) The only attributes allowed are those well known ones in the RDF /
RDFS specs.  All 'custom' properties and nested resource descriptions must
be specified as sub-elements.
   c) The rdf:type attribute on a rdf:Property element refers to the
property type.  Of course, any embedded resource is a sub-element of
rdf:Property anyway and will have its own rdf:type attribute.
   d) This simplification, although slightly less expressive, is more
obvious for human readers and would also make XSL Transformations a hell of
a lot easier to specify.

3) All RDF resources are referred to by URLs (not URNs) as attribute values
only.

4) Schemas and class definitions are not implied by namespaces, instead they
are easily located from the RDF identifiers (specified as URL attribute
values only).

5) RDF identifier abbreviations are outside the scope of the RDF spec.  Once
XBase becomes a recommendation, RDF documents can 'abbreviate' RDF
identifiers that way.

Just a thought...

Received on Thursday, 3 August 2000 10:13:59 UTC