On 2002-06-03 14:02, "ext Dan Brickley" <[log in to unmask]> wrote:


Sigh... OK, here we go... shields on full power ... ;-)


> On Mon, 3 Jun 2002, Patrick Stickler wrote:
>
>> On 2002-06-03 11:56, "ext Roland Schwaenzl"
>> <[log in to unmask]> wrote:
>>
>>> Dear Patrick,
>>>
>>> DC has fixed it's "namespace-policy" in
>>> http://dublincore.org/documents/2001/10/26/dcmi-namespace.
>>>
>>> About the usage of the namespace URI's it's saying:
>>>
>>> "All DCMI namespace URIs will resolve to a machine-processable DCMI term
>>> declaration for all terms within that
>>> namespace".
>>>
>>>
>>> Do you argue such use of namespace URI's is not legitimate?

>> Well, the debate over namespace documents, and whether a namespace
>> URI should resolve to some resource is currently unresolved and
>> under the scrutiny of the TAG, but my personal opinion is that
>> to allow a namespace URI to resolve to a document is to promote
>> a continued misunderstanding of the nature and purpose of
>> namespaces as defined by the XML Namespaces spec.
>
> Historically speaking, I think you're mistaken. The XML Namespaces REC
> came into being in large part because RDF and other apps needed it.

It's interesting to think of RDF "needing" namespaces since it discards
them when parsing into the graph. I.e. time and time again it is said
that the real heart and soul of RDF -- the *real* RDF -- is the graph model,
not the XML serialization -- and it is clear that namespaces do not
have any existence in the RDF graph (in their function as namespaces
at least).

> It
> came along at a time where there were a lot of contenders in the 'better
> than DTDs' space, ie. raw materials for the at-the-time-unformed XML
> Schema WG to continue.
>
> The studied neutrality you see in the XML Namespace REC regarding what, if
> anything, you might find by de-referencing a namespace URI comes in large
> part from pragmatism. If the spec had gone into that territory, it
> wouldn't be a REC yet. That careful avoidance should not be taken as
> implicit criticism of those who _do_ deploy documents at namespace URIs,
> just careful problem partitioning.

Well, while I can appreciate the political reasons for narrowing the
scope of a given specification, that doesn't mean that folks are free
to then go about pronouncing the spec to say more than it does. If
there is disagreement about anything further than what the spec says,
then there is also no global consensus beyond that point, and thus
no global web architecture beyond what the spec says.

It's OK for folks to build closed systems and get the job done with
whatever they need, but you seem to suggest that because some of
the folks involved in the development of XML Namespaces adhered to
a particular view, that that view is what is mandated by the spec.

Sorry. No.

The spec says that all that namespaces are is punctuation. That's it. If
the web architecture needs more, fine, then change the spec or define
a new one, but don't try to read more into the XML Namespaces spec.

If it doesn't say it, it doesn't say it, and no amount of druthers
will change that. Some folks may have wanted it to say more, but it
*doesn't* and we build systems based on what is agreed to by standards,
otherwise, what's the point in even defining the standards, no?

> In the Web, it is very natural for resource identifiers to resolve to
> their (possibly various) representations. In the Web, namespaces aren't
> magic, just another kind of resource. So we put their representations in
> the Web. It works pretty well.

This is the point of my disagreement. A namespace is punctuation. It is a
URI used not as a URI but as a globally unique identifier the sole
purpose of which is to be a globally unique idenfier. Period.

If that same URI is also used to denote some other resource, which
may be accessible, well, OK but I consider that to be a disjunct
usage of that namespace URI and as ambiguous and poor practice as
using a mailto: URL to denote a person.

>> There are several issues, of which I'll only touch upon one here,
>> and that is the relation of a term to a namespace within the context
>> of RDF. Namely, there is none.
>
> There is. We do not force every RDF implementation to keep explicit track
> of this, but nevertheless terms are related to their namespaces.

How? I don't see that we require any RDF implementation to keep
track of any namespace/qname information -- and furthermore, RDF
provides no native mechanisms to do that.

> We even
> provide a convenience relation, rdfs:isDefinedBy, to make it easier for
> apps that care to keep note of such information.

I disagree, Dan. The rdfs:isDefinedBy property does not point to
a namespace, but to a resource. And a given term can be defined by
more than one resource. That fact alone should be sufficient to
demonstrate that the object of rdfs:isDefinedBy is not a namespace
because a term, in its XML serialization, cannot have more than
one namespace (though, interestingly, since RDF discards the
qname partitioning, it could in several serializations be defined
with more than one namespace ;-)

If a namespace URI also denotes some resource that has any relation
to a term grounded in that namespace, that is a coincidence insofar
as the semantics of XML Namespaces and the RDF graph are concerned.

>> In an RDF graph, there are no namespaces, and there is no reliable
>> means to deduce the namespace that might have been used in the
>> original input RDF/XML serialization from a given term URI. Thus,
>> if an application is considering an RDF graph, there is no way
>> whatsoever for that application to obtain the "namespace" to which
>> that term "belongs" in order to even attempt to retrieve some
>> descriptive document that may define something about the term.
>
> There _are_ techniques. We provide rdfs:isDefinedBy, for example.

You missed an important part in what I said above: "from a given term URI".

And per my comments immediately above, rdfs:isDefinedBy takes any
arbitrary resource as its object, not just a namespace, and even *if*
a URI that is the object of rdfs:isDefinedBy is a prefix of a given
term URI, that still does not garuntee that it is the namespace of
that term when serialized as XML. The rdfs:isDefinedBy property does
not assert that its object is a namespace, and even if you know
the object is a namespace, it doesn't mean that namespace is ever
used to serialize that term.

Again, namespaces belong in the world of XML, and RDF is a different
world. Once you parse RDF/XML into the graph, you have *no* namespaces.
Poof. Their gone. Just like ENTITYs.

And it is reasonable that namespaces and qnames have no representation
or meaning in the RDF graph, otherwise, there would be an odd
assymetry between URIs denoting properties or classes and all other
URIs since the former will have namespace/qname definitions and the
latter will not.

Neither RDF nor the core web architecture use namespaces or qnames,
they use URIs. Namespaces/qnames are only meaningful to XML.

We still need a way to name and refer to vocabularies, document
models, ontologies, etc. *none* of which are required to
correspond to a single namespace.

> The fact that is (unless for eg you're an RDF parser keeping notes, or you
> have access to a database of popular namespaces) not always easy to
> acquire information about term-to-namespace relationships doesn't stop
> them being true, or being usable.

Again, just because a namespace URI is a prefix of a term URI
does not mean there is any relationship between that term and
whatever the namespace URI might otherwise denote. None.

Sure, it may be true that there are some cases where one can
finesse some correlation between a term, a namespace, and a
schema, but that is not provided for by the standard web
architecture. It's not a given. It's the difference between
best-practice or useful methodology versus actual standards.

It may be the case that e.g. the RDFS vocabulary is based
on terms all grounded in the same namespace which makes it
easy to write a single RDF schema defining those terms and
expose that schema at the same URI as is used for the namespace,
but just because it might work in that case does *not* mean
it worked because that is the way things are *supposed* to
be done. It just worked because *you* had full control of
everything and the vocabulary was manageable enough to do
it that way.

You could have just as well defined the RDFS vocabulary using
terms grounded in several namespaces and defined those terms
by multiple RDF schemas -- and once all that is syndicated
into the same RDF knowledge base, there is no functional
difference *whatsoever* from the single namespace, single
schema approach because you would have the same relations
between terms and semantics and between terms and classes,
etc and the URIs would be opaque, making whatever namespaces
you used for the XML serialization irrelevant. In fact, the
latter approach is far more
efficient when you start talking about large ontologies with
hundreds of terms and locale specific definitions for dozens
of languages and regions (I speak from experience here).

In the future, as vocabularies become larger and more
complex, such a simple model as all terms of a vocabulary
in the same namespace which also defines everything about
those terms and vocabulary in a single namespace document
will become untenable.

For us, it already is.

>> It can't be done. All you have are URIs, and any attempt to guess
>> at a namespace by looking at the lexical characteristics of the
>> URI, to e.g. strip of the maximal length of name characters from
>> the end, will not guaruntee you actually got the right namespace,
>> or any namespace for that matter. It's a guess. No more. And
>> solid, robust systems are not built upon guessing.
>
> (Google?)
>
> So this is misleading.

And Google searches are *robust*?! Rubbish. They are noise ridden
and require human intelligence to decipher.

And on the SW, I would hope we would have a bit more precision than
best-guess, since folks are so keen on truth and the legal burden
of RDF assertions. Sheesh, what a lawyer fest if we don't have
very accurate precision. Guessing? I don't think so.

Just imagine two banks talking between their ePortals: "Well, I'm
guessing the namespace of this URI is urn:xyz:blarg and the namespace
document from that URL tells me the rate of exchange for USD
to EUR is 87.2991, which since it appears to be a decimal
I'll assume I got the right data, so I'll just use that..."

Ummmm, no.

> Distinguish between (i) getting hold of the information (ii) using it.
> You're discouraging (ii) because (i) is hard with our current rdf/xml syntax.

No. I'm for both. I just see namespace documents as a short-sighted
hack that misses the forest for the trees. It works for a very narrow,
constrained set of examples, but not for the full set of cases valid
according to the related specifications.

What fans of namespace documents appear to be doing is trying to
impose a narrow methodology that works in some contexts as web
architecture that must be followed by all -- even when existing
specifications licence usage that conflicts with the notion of
namespace documents. E.g. I can use *any* URI as a namespace, so
don't tell me I now have to use an 'http:' URL just to store some
namespace document there which binds me to a monolithic, flat view
of my knowlege space. No thanks.

But I've shared my views at length on the TAG list and elsewhere. I
won't reiterate them all here again.

>> Furthermore, a given term may be defined by multiple resources, not
>> just one "namespace document", therefore the presumption that a
>> namespace dereferences to some resource that defines everything
>> about all terms grounded in that namespace is overly simplistic.
>
> This is a tangent, a corner case.

Perhaps for you, but we (Nokia) have been designing and using
schemas for a while now which deal with coverage, scoping, and
localization variation in this manner, and I hardly consider
what we are doing a corner case, but in fact, an example of
how RDF was meant to be used for large, multifaceted, structured
ontologies.

> A namespace document defines terms by
> describing then in rdf/xml and/or in prose. Other documents, messages,
> conference presentations etc might re-iterate or refine it.
>
> It seems reasonable for each rdf/xml term to have just one 'home'
> namespace, alongside annotations about it from elsewhere. This is the
> dominant model that people have used in deploying rdf/xml, I don't think I
> know of any counter-cases.

The error here is in presuming that there is a 1:1:1 correspondence to
a namespace, a vocabulary, a document model, etc. and there isn't,
even if there are many examples where that might, by coincidence or
from simplicity, be the case.

Take XHTML for example. There are three different functional vocabularies
and three different content models all grounded in the same namespace.
And from the namespace alone, you cannot know the full semantics and
structure of a given element. Don't belive me? Have a look at e.g. the
definition of the <html> element in terms of the Transitional versus
Frameset document models. Oops! Now how is TimBL and other proponents
that swear that the root namespace tells you what to do going to
deal with the fact that one cannot know whether to look for a <body>
or a <frameset> element. The namespace doesn't tell you. Nope. Again, oops.

namespace != vocabulary
namespace != document model
namespace != schema

namespace == punctuation

I know that alot of folks presume differently, but I think that
is simply a result of working with cases where, for one reason
or the other, such 1:1:1 correspondences existed (in *that* case).

>> It doesn't work that way in the real world. Terms are resources,
>> and our knowledge about those resources can come from many sources,
>> most of which have URIs bearing no relation whatsoever to the
>> "namespace" URI used in their XML serializations.
>
> That's fine.
>
> rdfs:isDefinedBy probably should have been called rdfs:ns, since we added
> it to RDF Schema as a way of associating a term with the wider bundle of
> names it was defined alongside.

But again, what you are really associating is the schema that defines
the term, not the namespace. This 1 term, 1 namespace, 1 schema view
is far too restricted for a tool such as RDF which encourages syndication
of knowledge from arbitrary sources.

If rdfs:isDefinedBy were limited only to namespaces, or even only to
RDF schemas, I would consider that to be a great reduction in needed
utility.

>>
>> There is an inherent incompatability between XML and RDF with
>> regards to namespaces -- namely that in the latter, they don't
>> exist.
>
> FUD. We just deal with them differently. We don't force RDF
> implementations to always have an encoding of the XML namespace mechanisms
> used in the RDF/XML that serialized each triple. But we do make it
> possible for terms to be related to namespaces, and to each other, in a
> genuinely extensible manner.

FUD. There are no mechanisms in RDF to preserve either namespace
structure or context. If there were, then round-tripping would be
a non-issue.

>       Again, there is no such thing as a namespace in RDF
>> semantics and there are no mechanisms in RDF for partitioning
>> terms according to namespace. Period. The presence of namespaces
>> in RDF/XML are an illusion. The namespaces have no semantic
>> reality. They are an editorial convenience, just like ENTITY
>> declarations. Once you parse the RDF, they are gone. Completely.
>
> Same mistake as above.

I don't see namespaces in the MT. They are mentioned there only
to introduce the editorial convenience of using qnames in the
examples. But the actual MT is based on URIs alone.
I don't see any requirements for parsers to preserve the namespace
structure. I don't see any namespaces in NTriples. The definition
of rdfs:isDefinedBy does not have an explicit range of e.g.
rdfs:Namespace.

I think you are imposing personal habits and preferences onto
what the specifications actually provide for and mandate.

I know that alot of RDF folks consider 'namespace' and 'vocabulary'
to be synonymous -- but that is not due to anything in any of the
specifications. Rather, we have a case where a given vocabulary is
denoted by a specific URI, e.g. "http://www.w3.org/2000/01/rdf-schema#"
and for reasons of economy and familiarity, that same URI is then
given double duty to serve as a namespace URI in XML serializations,
and hence, folks see the vocabulary and namespace as functionally
identical. But you could have just as easily named the vocabulary
"foo:bar" and the namespace "bas:boo" and ended up with just
as workable an ontology insofar as RDF is concerned. Likewise,
every single term in a given vocabulary could be given a disjunct
URI and each have a different namespace prefix yet still belong
to the same vocabulary, and RDF would be just as happy.

I again assert, namespaces have no formal presence in the RDF graph.
Namespaces are irrelevant to RDF. All namespaces provide to RDF
users is an editorial convenience enabling certain URIs to be
expressed as element or attribute names, as an aid to serialization,
but just as with ENTITYs,  once the RDF/XML is parse, the
namespaces are gone. Poof. Nevermore.

All that is meaningful and significant to RDF are full URIs, which
are fully opaque.

--

So the bottom line is that, if you want a property to relate a
term to a specific namespace then you need something other than
rdfs:isDefinedBy. And ideally, you would also instruct every
parser to always assert such statements for every term when
parsing. But no existing RDF mechanism provides for unambiguous
preservation of namespace structure.

Patrick

--

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: [log in to unmask]