W3C home > Mailing lists > Public > www-tag@w3.org > February 2005

Re: Significant W3C Confusion over Namespace Meaning and Policy

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 18 Feb 2005 09:03:40 +0200
Message-Id: <29f3b5b05857e5a28e5be4379881efc5@nokia.com>
Cc: <www-tag@w3.org>
To: "ext Jonathan Borden" <jonathan@openhealth.org>


On Feb 17, 2005, at 20:50, ext Jonathan Borden wrote:

> Patrick Stickler
>
>> Rather RDDL, or rather, the idea of namespace documents,
>> should just be dropped. Getting back a namespace document which
>> identifies all of the versions of all of the vocabularies,
>> schemas, ontologies, etc. employing terms from that namespace
>> is useless.
>
> I understand, but of course do not agree with, your first sentence. I 
> cannot
> parse the rest of what you write.
>
>> How is an application to know *which* version of *which* model to 
>> apply
>> in order to interpret the term in question? It can't, because a
>> given namespace is not tied to a specific version of a specific model
>> -- insofar as the specifications are concerned (and that's the key
> point!).
>
> Err, wouldn't that be up to the author of the specification?

*Which* specification? Multiple specifications and multiple versions
of the same model can share the same terms from the same namespace
(even if some versions or models use terms others do not).

How can the *client* encountering a term, and (if it's lucky)
obtaining a namespace document via the namespace URI of that
term, determine which version of which model to use to interpret
that term? It can't.

Yes, there can be corner cases where a given namespace is only
used for a single version of a single model -- but that's IMO
so constrained as to be impractical at best.

>
> The arguments that I think I am hearing from you (again, I have 
> difficulty
> understanding most of what you are writing) seem as though you are 
> arguing
> both orthogonally and abstractly to what I understand is the issue 
> being
> raised in this thread. Let me summarize what I understand is the main
> question here:
>
> Suppose the W3C (i.e. a particular WG) authors a specification i.e. 
> Version
> 1.0 of a particular REC. Later the W3C decides to revise the spec, e.g.
> emits Version 2.0.
>
> Also suppose that the REC is associated with a particular NS.
>
> The issue is: if Version 2.0 alters the syntax and/or vocabulary of 
> the REC,
> i.e. introduces new terms and makes others, to use the English meaning 
> of,
> 'redundant', ought the revised syntax use the same namespace URI or a 
> new
> one?
>
> A specific example is RDF Version 1.0 vs. 2.0.
>
> It seems that the confusion is that while it is stated that one ought 
> not
> use the same namespace URI when a vocabulary changes, that *in 
> practice*
> (e.g. RDF) the vocabulary changes while the NS remains the same.

Agreed. Though, of course, RDF is a bit different from XML in
that RDF has a much more flexible mindset about manditory vs.
optional use of particular terms. E.g. compare RDF (any version)
with the three versions of XHTML, where in the latter case, the
content model for certain elements differs from version to version,
yet the term is the same. In such cases, the model != vocabulary
(and for XML, I expect this is often the case) whereas with RDF,
often the model = vocabulary (though one should never presume
that to be the case).

Alot of the versioning issues relating to XML models are not as
significant to RDF models since RDF processors are typically
designed to deal with unknown terms gracefully. The only real
changes were to the parsers which needed to accomodate new
serialization issues when mapping between RDF/XML and graphs.

In hindsight, it probably would have been a good idea to (a) define
distinct URIs identifying the different versions of RDF, and (b) add
an attribute (not property) to the RDF/XML serialization on the
rdf:RDF element named rdf:version by which the version of the RDF/XML
serialization could be specified. Oh well...

(still, that is IMO the way to deal with these versioning issues, not
  based on the namespaces employed for terms but on the identity of
  the particular models governing interpretation of the data instance)

>
> -----
>
> Now I see the utility of obtaining an OWL document when dereferencing a
> namespace URI when in, for example, an RDF application, for example to
> obtain an ontology defining an RDF property.
>
> In the same way an XML Schema might be obtained when dereferencing a
> namespace qualitifed XML element name, and this might be used to 
> validate
> the content.

But *which* ontology?! *Which* XML Schema?!

Multiple ontologies/schemas/models/versions can all employ the same 
term!

Even if there is a namespace document obtainable via the namespace name 
URI,
you *still* have no idea which model identified in the namespace 
document
to employ. The agent still has to *guess*.

Better to tell the agent up front, for the data instance, which model(s)
should be used to interpret it, and not expect the agent to have to 
guess
based on (possibly but not guarunteed) information obtained via 
particular
namespaces.

>
> What we were trying to do with RDDL (aside of course from providing 
> human
> readability) was to develop a way to obtain any of (for example): an 
> OWL
> ontology, an XML Schema, a RELAXNG schema or a DTD, so that software 
> which
> understands each of the above specs would each be able to get what it 
> needs
> out of a namespace URI. RDDL was designed so that, if the vocabulary 
> author
> wished, XML documents would not ***necessarily*** be tied to an 
> ontology
> written in a specific ontology definition language, or a schema 
> written in a
> specific schema definition language etc.
>

I fully appreciate what RDDL tries to provide. I simply have not seen
any evidence that it (a) solves the problem of determining which
model to employ to interpret data or (b) can be retrofitted successfully
and broadly onto a web that does not use namespace name URIs to
identify namespace documents.

Regards,

Patrick


> FWIW
>
> Jonathan
>
Received on Friday, 18 February 2005 07:05:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:32 GMT