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

["Mason, James David (MXM) " <mxm@ornl.gov>]

I had already written my comments before I saw Michel's. I think we're all
on a path that can keep the work flowing, and I certainly welcome anything
on these lines that comes into SC34.

Jim

> -----Original Message-----
> From:	Michel Biezunski [SMTP:mb@infoloom.com]
> Sent:	Wednesday, March 21, 2001 04:43 a.m.
> To:	H. Holger Rath; Steven R. Newcomb
> Cc:	Ann Wrightson; Steve Pepper; Dr. James D. Mason
> Subject:	RE: [xtm-wg] ANNOUNCE: www.topicmaps.net: New informative
> web site on topic maps
> 
> 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
> ==========================================