RE: [xtm-wg] ANNOUNCE: www.topicmaps.net: New informative web site on topic maps

["Michel Biezunski" <mb@infoloom.com>]

Holger,

Thanks for your mail.

> SC34 started TMQL because we thought it will become
> as important for TMs as SQL is for RDBs and should
> therefore be published as ISO standard.

Yes, but this means also that topic maps must become as
popular as databases, which might happen some day.
By the way, do you know if SQL has been started by ISO or has it
been adopted by ISO after having been developed as a
proprietary language somewhere else (IBM?). Just curious.

> TMQL will define the "interface" to TM software
> (name it API or Query/Update language). This kind
> of interface - as we all know - has to work on a
> reference data structure (name it processing
> model or topic map graph - I am not that sure about the
> difference, but I hope you know what I mean here)
> with precisely defined data integrity rules (eg how
> the data structure looks like before and after a
> transaction). See attached architecture picture.
>
> At this point started the misunderstanding. Let me try
> to explain what we meant and what we discussed in the
> meantime with TopicMaps.Org Processing Model SG. SC34 will use
> the topicmaps.[org|net] processing model (PM) as its
> reference data structure and - if provided by the
> PM - its integrity rules (IR). SC34 will review the specs
> and give input if SC34 sees that some of the requirements
> TMQL has for PM and IR are not sufficiently fulfilled.

That's precisely what I want to do too. The reason Steve and I have
set up this web site is to enable everybody to be informed about our
work in progress. The development of this processing model means
a lot of work, and the only solution we have found to
work on it is simply to ... work on it (i.e, to free ourselves from all
procedural
and political issues which we feel are counter-productive when being
in a process of creating something new).

> This means that TopicMaps.* can develop the PM and related
> things at its own speed but will get input from the SC34.

It's our plan to continue discussing and interacting with everybody who
wants to do so. If you are interested by our processing model, good. We are
doing it
in the hope that it's going to be used. I am also interested to follow the
other
initiatives which are currently being developed in the hope that everything
will fall in place some day.

> SC34 will focus on the spec of the "interface" part. We do
> not even have the time/resources to standardize the TM PM
> in SC34.

Yes, but the foundations need to be agreed upon before you can design
the interface. It looks like this is what's missing now.

> >   under ISO rules, beginning with a requirements
> >   analysis and ending at some indefinite future date with an ISO
> >   standard query language for topic maps.
>
> You are right that ISO is working at a slower pace than
> TopicMaps.Org is able to. But you are probably also aware
> of the effect having this kind of spec published as an ISO
> standard. It is my deep feeling that TM or TM-like software
> will probably not replace RDBs but become as important as
> RDBs in the future. And it is also my deep feeling that
> we should have an ISO standard to specify the interface
> of these software systems.

I have nothing against the fact that ISO publishes our standards. On the
contrary, I think it's a good thing. But I think it's important that
organizations
are not used as obstacles against search for consistency. I am reluctant to
have dependent approaches being developed in different places, with
different
rules for membership, etc. It seems to me that it's also in the interest of
ISO that all pieces work together harmoniously -- and I have never heard
anything against that statement coming from a member of an ISO committee.
Therefore my attitude is to first try to find out what is the best technical
solution for global knowledge interchange, including but not limited to, the
whole Web, and after the technical problems are clarified, and after there
is some kind of agreement by a group of people, ask for help from the
standards organization to promote the standards, once proved to work.
Actually, this is what happened with ISO 13250. We only started the ISO
process after the specification by CApH was considered mature enough. Today,
we need to start from scratch to build a consensus. It's going to take the
necessary amount of time. I think if everybody is willing to succeed doing
that, we'll eventually
succeed. It's going to take time though, and we shouldn't underestimate
the learning curve, acceptance process, confrontation of various points
of view, etc. I feel confident that this is going to work, but this
necessitates
some adjustments from all of us.

> Ann and I will work hard to get a first CD of TMQL published
> until the end of this year. We will do this in a very open
> manner to allow other experts to contribute. Another goal
> of us is to get the scientific research backing. Something
> like TMQL gets very easy on the ground of non-computable
> or NP-complete problems - and we want to avoid running
> in this kind of problems from the very beginning (this is
> the reason why Ann mentioned her cantact to a UK university
> and get them involved in the process).

Good. You should also have a look on what's happening on the
Semantic Web activity, including DAML+OIL which seems to have a lot
of momentum these days. It looks to me there is some overlap with what
you are doing.

> >   My understanding of the
> >   mission of the XTM group was inconsistent with this plan: to publish
> >   a Web-oriented specification for topic maps, and to do it more
> >   quickly than any other standardization process could do it, mostly
> >   by relying heavily on work already done over the past several
> >   years.
>
> Of course, it is up to TopicMaps.* to develop its own
> TMQL after PM is done. But we would appreciate it very
> very much, if this work could be done together with
> joint forces/resources. Using the synergy between the
> speed and momentum of TopicMaps.Org and the stability
> of ISO standard.

ISO doesn't provide stability just because it's ISO. It depends
what's inside the standard. That's what I am trying to concentrate
on now.

> I hope my email brought some issues on the table which
> let you start re-thinking about your resignment from
> TopicMaps.Org.

Not necessarily, but I interpret your mail as a willingness that we
continue working together on topic maps. And I certainly want to
do that.

Best regards,

Michel
==========================================
Michel Biezunski, InfoLoom
Tel +33 1 44 59 84 29 Cell +33 6 03 99 25 29
Email: mb@infoloom.com  Web: www.infoloom.com
==========================================