[sc34wg3] The Norwegian National Body position on ISO 13250
Sun, 13 Apr 2003 17:04:39 -0400
Mary Nishikawa wrote:
> Thanks Steve,
> You said it better than I ever could have. What you describe is what
> we hope will happen in Japan. It is very important that SAM and XTM
> Syntax move to CD.
First, XTM syntax is already part of ISO 13250 so I don't understand why
it should be moving to CD?
Second, it is more important that the SAM be correct and useful than it
move to CD.
Let me illustrate one problem that I see with Steve Pepper's reasoning
for moving the SAM to CD:
Steve Pepper says (copied from below)
A bigger problem is that new tools are appearing claiming to
support topic maps. What we see, especially in Norway, is that
the increased interest for topic maps is leading to the
development of "topic map" software by people who have not
participated in the standards process. In itself this is
obviously very welcome. The trouble is that the lack of
guidance in ISO 13250 is leading to systems that are severely
Perhaps I am unclear about what Steve Pepper means by non-conformant but
I am reading this to mean that topic maps are treated differently
depending upon the application with which they are processed. He may
also mean that these applications are not following the syntax rules of
ISO 13250 but I cannot tell from this post. (Steve, can you shed some
light on what sort of non-conformance is meant?)
Now, consider a post from Lars on merging rules in the SAM (for those of
you who missed it:
***Post from Lars***
| Specifically, the SAM does not say how (or even whether) the
| instances of user-defined association types can determine or
| influence whether their role players should merge.
It does not say how, but it does say that this is allowed:
"Merging is a process applied to topic maps in order to reduce the
number of redundant information items representing the same
information. Merging is required to be performed in certain cases,
but this is insufficient to guarantee that there will always be one
topic per subject. Applications are therefore allowed to merge
topics as they see fit." -- 4, first para
If you want to argue that this should be broadened to cover all item
types I'll buy that.
But, again, no restrictions have been placed on the allowed mechanisms
for doing or expressing merging because this is seen as something for
which applications should have freedom to do as they choose with.
***/Post from Lars***
At first blush that appears to leave merging rules up to the individual
application, which will surely lead to differing results when processing
the same topic map. By analogy, it would be like ISO 8879 allowing
applications to choose their own concrete reference syntax while obeying
all the other rules. Would certainly limit the portability of SGML
> I'll say it again, we need to demonstrate that our standards work is
> actually leading to benefits for Japan. It is very hard to do so, if
> we only continue to do remodeling on a model, or keep one model on
> hold until we do remodeling over and over and then change the names
> and terms in the model, etc.
Standards efforts need to benefit the the entire public community. I
understand the need to also frame that benefit in terms of the interest
of our various national bodies.
It will be even harder to show a benefit if a model, any model, is
pushed prematurely towards CD and perhaps to a standard that allows the
results to vary depending upon the application that I am using. I can
interchange PDF or Postscript documents between applications with
predictable results. Is it too much to ask for the same for topic maps?
> At 00:14 03/04/13 +0200, you wrote:
>> Without engaging directly in the various debates taking place
>> at the moment, I would like to state the position of the
>> Norwegian National Body, so that committee members are aware
>> of it in advance of the London meeting.
>> It can be summarized as follows:
>> The Norwegian NB believes it is of the utmost urgency to
>> move both the SAM and XTM forward as soon as possible.
>> Our experience in Norway is that industry demand for topic
>> maps is exploding. Over 70 people attended the conference
>> "Topic Maps Norway" last fall; this winter 60 people turned up
>> for a one-day seminar entitled "Topic Maps for Librarians";
>> and just last week, 100 people packed the room for the first
>> meeting of the Norwegian Topic Maps User's Group to hear about
>> "Topic Maps for Portals". All this in a country of just 4
>> million people!
>> Upwards of a dozen topic map projects have either gone live or
>> are under development in Norway (and that's just to our
>> knowledge). A whole slew of topic map-driven portals and web
>> sites have already been built for bodies such as the Norwegian
>> Research Council, the Norwegian Consumer Association, the
>> Norwegian Defence, and even the Norwegian Conservative Party!
>> (The latter a very cool application, by the way.) At least two
>> major projects that connect government institutions and local
>> authorities are well underway, and topic maps are starting to
>> appear as a requirement (alongside XML) in important RfPs.
>> Obviously this is very good news, but there are problems as
>> First of all, there is the compatibility problem.
>> ISO 13250 as it currently stands is woefully inadequate for
>> implementors. The only reason we have half a dozen or so
>> reasonably compatible commercial and open source topic map
>> engines today is because their developers were active
>> participants in either ISO, TopicMaps.Org, or both. Even with
>> these tools, we do not yet know how compatible they really
>> are, because we have no way of testing conformance.
>> A bigger problem is that new tools are appearing claiming to
>> support topic maps. What we see, especially in Norway, is that
>> the increased interest for topic maps is leading to the
>> development of "topic map" software by people who have not
>> participated in the standards process. In itself this is
>> obviously very welcome. The trouble is that the lack of
>> guidance in ISO 13250 is leading to systems that are severely
>> This problem is going to get worse and worse as time goes on
>> and we believe it could pose a serious threat to the standard.
>> The only solution is to finalize the SAM and XTM specs as soon
>> as possible, with CXTM following soon after.
>> Secondly, the uptake of topic maps is leading to a very real
>> industry demand for TMQL and TMCL.
>> Companies implementing portal solutions, in particular,
>> experience very quickly that without a constraint language
>> they have to put inordinate amounts of effort into building
>> proprietary checks and constraints into editing applications.
>> It is therefore not surprising that the company responsible
>> for implementing the portals mentioned above (not Ontopia, by
>> the way) has asked the Norwegian National Body to press for
>> faster progress on TMCL.
>> The same applies to TMQL. As soon as people start building
>> real applications of any size around topic maps, the need for
>> a query language becomes acute - not least in order to achieve
>> scalability. Implementors in Norway are demanding a standard
>> query language.
>> However, neither TMQL nor TMCL can get past the requirements
>> stage without an approved data model on which to build. So,
>> once again, progressing the SAM is a matter of real urgency.
>> In our opinion, progressing the SAM should not present any
>> problems. The specification has been remarkably stable for two
>> whole years. Anyone who doubts this is invited to compare N396
>> (the current draft) with N356, N329, N299, and N229.
>> The SAM is mature. There are very few issues remaining and its
>> relationship to the XTM, HyTM and CXTM specifications is very
>> clear; all these four parts fit together seamlessly. (HyTM and
>> CXTM may not be quite ready for CD stage yet, however. The
>> London meeting should show us if this is the case.) The only
>> possible reason for delaying the SAM would be the lack of
>> clarity regarding its relationship to the RM. However, this is
>> as much as lack of clarity regarding the role of the RM. The
>> SAM itself does not need the RM. It stands on its own and is
>> capable of supporting 2 interchange syntaxes, a canonicalization
>> format, TMQL and TMCL. It need not wait for the RM.
>> We believe that the latest version of the RM (misleadingly,
>> erroneously, and unofficially called the "TMM") is a significant
>> improvement on earlier versions, but it is still immature and
>> has yet to demonstrate that it actually does what it claims to
>> do - i.e., provide a foundation for defining "topic maps
>> applications". The fact that it changes beyond recognition
>> with each major version gives a clear indication that it still
>> requires more work. The Norwegian National Body is prepared to
>> support that work, but not at the expense of progressing the
>> other parts of the standard.
>> For these reasons, the Norwegian NB will be pressing for the
>> SAM and XTM to move to CD stage at the London meeting and we
>> will be soliciting the support of other National Bodies in
>> Best regards,
>> Steve Pepper <firstname.lastname@example.org>
>> Chief Executive Officer, Ontopia
>> Convenor, ISO/IEC JTC 1/SC 34/WG 3
>> Editor, XTM (XML Topic Maps)
>> sc34wg3 mailing list
> sc34wg3 mailing list
Director of Research and Development
Society of Biblical Literature
Co-Editor, ISO Reference Model for Topic Maps