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/>