Re: [topicmaps-comment] RE: OASIS vs W3C

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Lars Marius Garshol
|
| This is a very dangerous thought! Whatever else PMTM4 may be for, it
| is not for interchange.

* Sam Hunting
| 
| We are agreed in this -- I wrote in "specialized *in markup* for
| interchange", meaning that interchange was the purpose of the markup.

Good!
 
* Lars Marius Garshol
|
| Like Holger says the templating mechanism in PMTM4 is too weak to
| really be useful for anything other than cause confusion by
| representing a useless alternative to the real solution, TMCL.
 
* Sam Hunting
|
| Well, Lars, I think I'll decline the invitation to flame. 

You are right that this was somewhat agressively worded. :-)

| I will note only that PMTM4 is stable, mature, and has been
| implemented several times, whereas TMCL is (in your own words) a
| "straw man". 

My point was not that PMTM4 was useless, but that it was useless as a
schema language. PMTM4 is a data model, TMCL a schema language. They
do not compare, as you note. The only problems are that

 a) you claimed it could perform the functions of a schema language,

 b) PMTM4 invites this misunderstanding by using the concept of
    association templates

You do raise one thing I've been curious about for a long time,
though: where are all those implementations of PMTM4?

Also, my words were _not_ that TMCL was a strawman, but that TMCL was
currently at the strawman _stage_.

| Sounds like apples and oranges to me. 

To me as well.

* Lars Marius Garshol
|
| Another thing is that to mix the schema language into the foundations
| of the data model is likely to lead topic maps to come down with a
| very severe case of gordic knot of the bootstraps.
 
* Sam Hunting
|
| Way too complex for my simple mind, I'm afraid. Again, people have
| implemented it, so the presumed issues that you raise have been
| resolved somehow, eh?

This isn't about the problems for implementors, but the problems this
poses for specification writers. The approch followed by RDBMSs, XML,
SGML, RDF, STEP (ISO 10303), and so on is to first define a data model.
The data model restricts what kinds of things you are allowed to say
at all and how.

Then, they define schema languages that let you control in more detail
how you are allowed to work within the data model. The crucial point
is that the schema langauge constrains the allowed form of expressions
within the data model, and so is based on it.

What you propose to do with PMTM4 is to have a core model, and then
build topic maps using that core model. Once you've done that it
becomes very difficult to use the core model as a schema language for
topic maps (the thing build using the core model). The result ends up
looking like

  <URL: http://www.worldofescher.com/jpgs/A63Lg.jpg >
 
| I'm simply reflecting on what seems to be a difference in design
| philosophy or focus between RDF and XTM -- RDF schema speaks many
| times of "machine-understandable [sic]" vocabularies.

XTM is also intended to be machine-understandable to the same level
that RDF is, in fact, it is likely to be machine-understandable to a
higher degree than RDF. 
 
| I suppose that topic maps are a basis for such vocabularies, but the
| stress in XTM that (again) "humans are the ultimate arbiters of
| subject identity" means that resources that machines might
| "understand" to be different in RDF might turn out to be the same in
| XTM (or vice versa) once humans were put in the loop. And a good
| thing too!

I think this difference is mainly one of philosophical focus, and
without much impact on how XTM and RDF get used.

That humans are arbiters of subject identity means that while the
system is running humans might intervene and decide that two topics
are the same. This corresponds to having humans be able to modify the
topic map, which they would of course be able to with RDF as well,
should they want to.

What this does not mean is that machines can't understand or use XTM
because they are paralyzed and waiting for a human being to tell them
what is what.

To put it another way, this doesn't affect the extent to which
machines can use topic maps in any way. If I make a workflow system
where the workflow definition is a topic map the fact that humans
_might_ decide to merge some of the topics representing the workflow
definition does not affect the system in the slightest. (Well, except
insofar as you might want to remove that possibility for that
particular system. At least at runtime.)
 
| As for practical implications, what do you mean by practical?

I meant: what does this difference mean for applications of topic maps
and RDF? How does it guide me when I want to decide whether to use
topic maps or RDF? 

--Lars M.