[sc34wg3] TMQL, State of Affairs

[Martin Bryan]

Robert

The UK position is being somewhat misrepresented in your responses, and
generally in what I have heard to date. Our point is that you have to
explain to the world outside of the small community of developers involved
in TMQL why yet another query language is needed, and why XQuery or
somehting based on the tried and tested ISO-standardized SQL approach would
not do just as well. If the editors can add a clear case for having a new
language the UK would be happy. If it could be proved that a separate
language is needed for either scalability or efficiency reasons then we
would be even happier. But to say "we think this is better" without proving
that it is either more scalable or more efficient than existing languages is
not acceptable. You have to give readers without any previous experience in
Topic Maps confidence in your currently insufficiently justified decision to
start afresh when it comes to defining a query language for topic maps.

Martin Bryan


----- Original Message ----- 
From: "Robert Barta" <rho@bigpond.net.au>
To: <sc34wg3@isotopicmaps.org>
Sent: Monday, May 23, 2005 12:51 AM
Subject: [sc34wg3] TMQL, State of Affairs


> Hi,
>
> Even under the risk that this cannot be properly digested before
> Ams'dam, a few short remarks; also in the light of the UK NB position
> on the feasibility of TMQL:
>
>   - The spec is more or less in itself consistent (well), modulo
>     the exception where we (Lars and /me) need feedback and guidance
>     from the committee. Lars will certainly walk through them.
>
>   - The parts concerning the _formal_ semantics have NOT been written,
>     because partly they depend on the above and depend of what happens
>     with TMRM. Doing this sort of work takes _MUCH_ time, so we want
>     to do it ONCE only. We do not have the resources like, say, the
>     SPARQL people.
>
>   - Speaking for myself, I do not have any strong feelings that TMQL
>     should move forward in the standardization process. More important
>     to me is the concensus, whether the current draft the way to go or
>     whether larger changes are to be made.
>
>   - Regarding the doubts whether TMQL is implementable, several
>     comments:
>
>      - It seems to be. :-)
>
>      - The spec should contain enough _informal_ semantics to understand
the
>        machinery (with a few exceptions). It is boring (!) read, I admit.
>
>      - Mapping TMQL onto a relational schema simply proves that a TMQL
>        expression can be mapped into an SQL expression. If we assume that
>        SQL is sufficiently powerful (Turing complete?), then this proves
>        almost nothing.
>
>        Mapping TMQL onto XQuery simply proves that a TMQL expression
>        can be mapped to an XQuery expression. Otherwise, same argument
>        as above.
>
>      - What is probably meant is the scalability of such mappings, but
>        'Scalability' is a _design_ criterion which may depend on the
>        application. No computer language 'scales' per se.
>
>        Give me _any_ relational database on _any_ database platform on
>        _any_ OS on _any hardware. I can bring it to its knees.
>
>        Give me _any_ programming language on _any_ platform. I bring
>        it to its knees.
>
>        Scale with what, anyway? Number of users? Number of queries per
sec? Size
>        of maps, complexity of maps? Complexity of the inferencing
ontology?
>        Complexity of the query statement?
>
>     I guess, it is as it is: Some queries will be fast in a particular
>     implementation, some will be slow. If someone uses this together
>     with higher-order inferencing, then queries might not even
>     terminate!
>
>     The developers/users rule and decide.
>
> \rho
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>