[sc34wg3] TMQL, State of Affairs

[Robert Barta]

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