My Private TMQL
Having decoupled myself from the standardisation process had an extremely beneficial consequence: I could push my own TMQL implementation forward.
I commented out some of the cruft which I only maintained to keep some co-editors happy. Among the prominent victims is the SELECT clause which is by far the most convoluted flavour of TMQL. I also removed all references to CTM. It is too complex for me at the moment.
Instead, and mostly for my better understanding, I reinstated the ontological aspect of TMQL (as once proposed in 2006/2007): With it you can specify (and import)
- ontologies (i.e. other maps together with a namespace)
- functions, and
- virtual associations (aka rules)
The nice thing about all this is, that they come with minimal syntax and implementation cost. Each of the above is actually "only a topic" and function bodies and virtual associations are also written in TMQL. What else?
That also paved the way to include ontological constraints, constraints in the sense as in TMCL. But in my implementation the constraints themselves are also written in TMQL. The only necessary addition was the ==> implication operator. So in this sense, an TM ontology language is simply an extension of TMQL.
I guess you can see the advantage of having all (constraints, ontological rules and queries) based on the same semantics. I have not yet exploited this in my implementation, though.
What I also experimented with, was to include temporal operators such as before or after. But here I realize that my existing Topic Maps implementation simply will not perform efficiently. No real surprise here, but it implies a rewrite of major parts of my core.
While we seem to have found a way to express locality in AsTMa, I am still very unsure how this should pan out in a query and then an ontology language.
The current thinking is to actually keep it out of the query language and only bless some specific association types as being geospatial.
As my implementation strategy is around evaluating low-level path expressions, my optimizer is all about making them shorter and less costly. All the optimization rules I have are of the kind
So each rule tries to find the part on the left of ===> and replaces that with the expression on the left. You can find the rules side TM::QL::PE (further down).
While at the time of programming I had played with the thought using Prolog or Haskell for that, for some reason I implemented this tree matching and transforming process in pure Perl. Needless to say, that this is not overly fast.
But I might now have found a way to make this blindingly fast. Will report here about any interesting findings.
Still Not Happy
As I am not a strong believer in the separation of
- assertion language (such as CTM, AsTMa),
- constraint language (such as TMCL),
- ontology language (such as OWL-TM), and
- query-transformation language (such as TMQL)
I rather want to have just a single language. And that would also include updates: Updates of complete maps, but also fragments of them.
A simple example looks like this:
Obviously, a new name will be added to the topic rho inside the map users on that server. The path expression / name just points to the names.
Or something which already is implemented in TM::Tau:
The above converts an XTM map to an AsTMa map. A simple RESTification would later allow this too:
That stores the complete map with PUT onto the RESTful server. That is using the existing TM::IP protocol which I need for my map visualisation infrastructure anyway.
Getting Greedy (Or Visionary)
All that is just the beginning :-)
Following the vision of other RESTafarians (most prominently Robert, Alexander and Andrew) I want to see the language eventually morph into a TM programming language.
I'll wait until you recover from the shock ..... .... ... ..... .... Ok, welcome back.
It should be quite declarative (think rules) and function oriented (think LINQ, Scala) and instead of the OO-drivel all data -- actually all information -- is modeled with TMs.
All hopefully in less than 500 lines of Perl. Everything else would be too big.