Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 17, 2005, at 16:53, ext Harry Halpin wrote:

>
> I completely agree - I think Patrick is also missing the point. First,
> Patrick talks quite often of "models" - I'm not sure what exactly he 
> means. In the areas I'm familiar with, such as programming language 
> semantics or ontologies, models mean a mapping from some syntactic 
> form
> to some mathematical object (such as lattice, first-order predicate 
> logic, or an abstract state machine ala operational semantics) with 
> well-understood properties. So what "model" is being talked about, and
> how does it solve the problem of versioning in a both human and 
> machine-usable manner? Can you provide me an abstract "model" of a 
> URI,
> or URI usage? And if you have a model, how are you going to communicate
> about it over the Web? And if you are going to communicate about it 
> over the Web, it makes sense one is going to use a URI to do it? And 
> whether
> one choses to put the version info in a URI (such as 
> www.example.org/xml/2.0/namespace or just 
> www.example.org/xml/namespace
> or www.example.org/xml/2.0/namespace/element or 
> wwww.example.org/xml/2.0#element?) it seems either way the obvious
> place to put *more information* is either in the URI or a namespace 
> document. Why not provide standards for both, so applications can get
> this *obviously* needed information?

Please see my comments in

http://lists.w3.org/Archives/Public/www-tag/2005Feb/0164.html

Yes, one should use a URI to identify which model (schema, ontology, 
etc.)
should be used, but that URI should not be the namespace name URI 
because
multiple versions of multiple models can employ the same terms grounded
in the same namespaces.

>
> And yes - of course people mix and provide new versions of namespaces 
> - that's exactly the problem we're trying to solve. Saying this is a 
> *problem*, denigrating a solution (namespace documents), and then not 
> providing any positive solution is not solving the problem, it's 
> ignoring it.

Interesting. So, if I know that one answer is wrong, but am
not entirely sure of what the correct answer is, I am ignoring
the question?

I may not know which might be the best route to take to a given
destination, but if I do know that a particular option goes
in the wrong direction, I think it's useful to say so.


>  And then saying it's not "licensed in the spec" is fine if it isn't - 
> Henry and Roy and such already told us exactly what was in the spec - 
> but obviously for some (not all, but some) people are having problems 
> here. So
> why not try to think of a solution, and if it proves useful, it may or 
> may not be added to the spec, or be provided as an optional spec?
>

C.f. http://lists.w3.org/Archives/Public/www-tag/2005Feb/0164.html
for some suggestions to the real problem.

> I think a namespace is a perfect place for information about 
> ontologies and schemas. A URI is one of the few things a person can 
> own on the Web,
> and so it puts the vocabulary\schema\ontology elements in a location.

But far better to publish information about the model (schema, 
ontology, etc.)
to be used to interpret a data instance via a URI identifying the model.
Trying to arrive at the model via the namespace name of some term is 
just
a guessing game that will not have globally ubiquitous deployment.

Namespace documents is a sub-obtimal solution due to management 
scalability
and one-to-many ambiguity even *if* there was globally ubiquitous 
practice.
It is not a solution to the real problem, which is which model(s) to use
to interpret some data instance.

> If the URI is part of a namespace (as in xmlns is used to identify 
> part of the namespace), the value of putting a namespace document with 
> both human
> and machine-readeable data in it should be obvious - how else are you 
> going to know what an element in the vocabulary\schema\ontology means 
> in human readable terms, and where can the RDF describing soemthing be 
> gotten from? How else are you going to get information about the 
> model, especially if  you are dealing with changing and potentially 
> unknown models?

Gee...  that seems like the problem that we need to solve. Thus,
rather than clinging to a sub-optimal solution, let's try to work
out a more scalable and backwards compatible solution.

C.f. http://lists.w3.org/Archives/Public/www-tag/2005Feb/0164.html for
one suggestion.

> The Web is too big for RSS-like namespace change propagation, and
> we need decentralized, not Web-wide centralized solutions. Namespace 
> documents are decentralized to the owner of the URI of the namespace.

Right. Decentralized as in, the owner of the model identifies the
model with a URI and publishes information (both for humans and
machines, ideally) via that URI, and there is a simple, standardized,
and consistent mechanism for identifying the model to be used to
interpret a given data instance in that data instance, using the URI
of the model, such that the recieving processor (or human) can
obtain the information necessary to properly interpret that data
instance.

Namespaces are syntax. Leave them there. Focus on the models.

>
> It's obvious RDDL or something like RDDL needs an upgrade to deal with 
> versioning.

Actually, it seems more obvious that versioning concerns models
not namespaces and unless you subscribe to 
one-namespace-one-model-one-version
(which is false) RDDL can never adequately address the versioning
problem.

> If someone else wants to do the versioning in the URI, that's
> fine too, but I think doing it in a namespace standardized RDDL-like 
> thing
> is more likely to provide consistency. And then one can mix, change, 
> and add things to namespaces - it's just that the namespace document 
> could
> reflect that, and different namespaces would resolve to different 
> documents. This is so obvious I'm somewhat surprised to have myself 
> enumerating the benefits.

Well... I think that when you consider that there is no 1:1 correlation
between namespace and model, much less version of a model, those
benefits quickly disappear.

> And it won't be required - plenty of people don't use RDDLs - but 
> those that do should be allowed to. And the positive value of using
> standardized ways to talk about versioning and namespaces may provide 
> such utility that others will. There's no "MUST" there to "make 
> someone use a namespace document" - there is only an option. In the 
> words of RMS, to give the users more freedom - but without subtracting 
> from interoperability.

I'm not opposed to folks using RDDL or namespace documents of
any type. In fact, I suggest a very useful application of
RDDL like documents as representations describing models and
resources relating to the model (not namespace) in my recent
posting. I simply point out that namespace documents take the
wrong architectural focus to properly solve the actual problem
at hand, cannot become globally ubuiquitous, and have significant
management scalability issues.

I.e., however much utility RDDL and/or namespace documents might
provide to some, it is not an adequate solution to the problem
of how a recieving agent is to know which version of which model
to employ when interpreting the data -- whether that agent is
human or machine.

Patrick



>
> 				-harry
>
>
>  On Thu, 17 Feb 2005, Robin Berjon wrote:
>
>>
>> Elliotte Harold wrote:
>>> Patrick Stickler wrote:
>>>> 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
>>> It's not all about machines. In fact, RDDL was invented primarily 
>>> because humans were having trouble with this stuff. Machine 
>>> processing was an afterthought.
>>
>> And to take Elliotte's point further, if namespace documents as 
>> currently defined in RDDL and other proposals cannot handle multiple 
>> versions (and profiles) of a vocabulary (which is indeed the case) 
>> then let's make them handle it. The last time I recall namespace 
>> documents being brought up to the TAG the answer was IIRC "after 
>> we're done with AWWW v1". This seems like a good requirement to add 
>> to the list, in hope that the TAG will tackle it sooner rather than 
>> later.
>>
>>
>
> -- 
> 				--harry
>
> 	Harry Halpin
> 	Informatics, University of Edinburgh
>         http://www.ibiblio.org/hhalpin
>

Received on Friday, 18 February 2005 08:24:36 UTC