Re: tolog for TMQL

Lars Heuer <[email protected]>
Newsgroups gmane.text.xml.xtm.general
Message-ID <[email protected]>
Hi there,

Off-list discussions continue, but I think it's better to discuss
these things in public.

A few arguments from the discussion against tolog:

* Standardizing tolog gives Bouvet/Ontopia an advantage in competition

I don't think so since the the standardized tolog wouldn't be that
tolog which is used by Ontopia/Bouvet now. The standardized tolog
would be incompatible to the current tolog. Ontopia may have gathered
some knowledge about optimizing queries, but Ontopia is Open Source,
feel free to learn from them.


* Ontopia dominated the standardization process already too much, we
shouldn't follow them blindly.

Agreed. But I don't propose to take tolog as it is.


* tolog does not use TMRM as foundation

The current TMQL proposal does not use TMRM either. A TMRM user can
introduce predicates to support TMRM.


* A path language would be less verbose

We have the opportunity to introduce a path language later (SPARQL may
get a path language as well). We fucked up TMQL already and we don't
have more time to loose.


I am not affiliated to Ontopia/Bouvet and I don't get money from them
to propose tolog (well, I wouldn't mind if they send money, though
;)). I think using a modified tolog is simply the right step *now* and
using tolog wouldn't prevent a path language later. It's a shame how
much time, money, resources and editors we lost already. Feel free to
take a look into the history of TMQL development. The undirected,
repeatedly starting from zero design of TMQL lead to nothing and I
don't see any light at the end of the tunnel. The lack of a
standardized query language puts a lot of (potential) Topic Maps users
into an idle mode. Everybody is waiting that the ISO produces
something usable. And the development process of TMQL has failed for
10 years and created a few island solutions (TMLab's TMQL impl, tolog,
TempleScript, Toma). It's time for a solution and a modified tolog is
a solution. Maybe not the solution we hoped for, but it's a solution
which does not prevent further enhancements (path languages bla bla)
later and makes Topic Maps more attractive for users outside of our
ivory towers.

Best regards,
Lars
-- 
Semagia
<http://www.semagia.com/>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.