[sc34wg3] Roadmap to the topic map standards

[Lars Marius Garshol]

* Patrick Durusau
| 
| Overall +1 (minor comments below):

Ah, good. :-)
 
* Lars Marius Garshol
|
| The current ISO 13250 only defines a number of technical topic map
| terms as well as two interchange syntaxes, but it does not define
| the structure of the model that these two syntaxes are intended to
| represent. Neither does it clearly define the relationship between
| the two syntaxes, and as there are some subtle differences between
| their structures, this is important.

* Patrick Durusau
|
| Rewrite concluding sentence to read: "Neither does it clearly define
| the relationship between the two syntaxes, and there are some subtle
| differences between them.

I buy that. (Applied.)
 
* Lars Marius Garshol
|
| So while the community is generally satisfied with the two syntaxes,
| their specifications are in need of improvement on three counts:
| 
|     * They are lacking in rigour.
 
* Patrick Durusau
|
| Rewrite to read: They lack formal a formal model for topic maps.
| 
| Assuming that what you mean by "lacking in rigour" is the absence of
| a formal model. Or is your comment more generally on the coherence
| of expression in the standards?  "(L)acking in rigour" could be
| either one or both.

Well, what I mean is that both specifications have large gray areas
where it is anything but clear what happens. I don't think these areas
are visible to those don't have to implement this stuff, but to us who
do they are very troubling. So the problem is the lack of rigour in
the sense that there are ambiguities that shouldn't be there, and the
model is just the preferred fix to that problem.

I *could* have written that they lack a formal model, but that would
be confusing the fix with the problem, and I wanted it to be clear why
we needed a model. 
 
* Lars Marius Garshol
|
|   * They do not provide suitable foundations for the TMQL and TMCL
|     standards.
 
* Patrick Durusau
|
| Rewrite to read: "They do not provide the formal models required for
| TMQL and TMCL standards."

Again, this is mixing up the problem with its preferred solution. I
realize that we may not want clarity here (as the situation is bad,
and so honesty makes us look bad,) but there was a definite reason for
choosing this wording.

Input on what we prefer is welcome.
 
| Note that I am assuming you will need both the Reference Model and
| Standard Application Model to underlie TMQL and TMCL. Obviously the
| latter is of greater concern but theoretical work on TMQL/TMCL
| should refer back to the RM?

Formally the basis of TMQL/TMCL will be the SAM, but the RM will
underlie TMQL/TMCL in the sense that it should teach us how to ensure
that TMQL/TMCL can handle SAM changes and alignment with other
standards. I guess the way to handle this is to insert extra text that
clarifies this.

| (I suppose part of my concern is that the two models are consistent
| with each other, although one (RM) will be more abstract than the
| other (SAM).)

They definitely do need to be consistent with one another, but the
mapping between them (to be written by SRN & MB) should take care of
that, I hope. Additional maths work would also help. I guess I should
add text to explain this as well.

| Rewrite first sentence to read: "The new ISO 13250 will also include
| a model known as the Reference Model, which is a more abstract model
| of topic maps."
| 
| Not certain that we need to commit ourselves to a particular
| methodology of modeling, i.e., graph, for the Reference (or any
| other) Model.

That's a valid point, I think. On the one hand we think we will use
graphs for the RM, so we should say so, but, as you say, we might
conceivably change our minds. One solution to this is to move "graph"
out into a separate sentence, so we can qualify it appropriately. 

On the other hand, the editors of the RM seem pretty much committed to
using graphs, so I think I'd like to hear what they say before
changing anything. SRN? MB?

| I am not saying there is any problem with using graphs for the
| modeling, but questioning the need to commit to any methodology as
| the "correct" one before a successful model has been constructed. It
| may well be the case that for explanatory purposes, the revised ISO
| 13250 may offer isomorphic versions of the Reference (and SAM)
| Models using more than one methodology.

That is true, in fact, given the maths work it is even likely, but
there is a conflict here between giving as much information as we can
and telling people things that might change. The best resolution is
perhaps to add a paragraph explaining this issue.
 
| Suggestion: Rewrite as: "Below is shown a conceptual diagram of the
| relationship between the different part of the new ISO 13250:"
| 
| and then produce the diagram limited to ISO 13250.
| 
| Then write: "Below is shown a conceptual diagram of the relationships
| of ISO 13250 and TMQL and TMCL:"
| 
| and then insert diagram that shows the relationship of TMQL and TMCL
| to both HyTM and XTM. (The present diagram only showing a relationship
| to the SAM, which I realize implies a relationship to HyTM and XTM but
| only by implication. Or, is the difference because TMQL and TMCL will
| be defined in reference to the SAM model and not defined as syntax for
| application to HyTM and XTM?)

Exactly. The idea is that TMQL and TMCL will not be based on XTM or
HyTM at all, but directly on the SAM instead. (They will relate to XTM
and HyTM through the SAM, but not directly.) In fact, as the document
(tries to) explain, XTM/HyTM do not provide a suitable basis for such
a specification. When you define a "find all base names of topic Y in
scope X" query operator it is very hard to explain what it does in
terms of the syntaxes, especially as you'd have to do it twice because
there are two syntaxes. Explaining it in terms of the SAM is *much*
easier. 

Hmmm. It seems I need to explain this more clearly as well. :)

Thanks a lot, Patrick! This was good stuff, exactly the sort of
comments I needed. The problem with having me write this stuff is that
I tend to assume my readers know more than they do, and that's
definitely not the right thing in this case. Ah well, I'll produce a
new draft once I've had some more comments.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >