Hi! CatBert here.
Gosh. Robert is soooo easy to play: I only had to show him how a web application can be expressed with my TM based language TempleScript. As expected, he first appeared to be all negative about it, but I just know him too well. Now he is hooked and off doing the conceptual footwork for me.
Which allows me to sleep more and dream up more ambitious things:
A Topic Maps based mashup infrastructure.
Obviously I managed to send CatBert back into deep depression (he saw that coming, trust me).
While he sleeps in his favourite armchair, I can steal back my ideas and tuck them safely away into an academic paper. So maybe another RDFascist can entertain me with a negative review. As if a man with a vision would care.
Among the things I want to add to TempleScript are subject locator patterns. Here is the use case:
Life is full of coincidences: First I followed with interest the Ontopia web dev tutorial, then I had my more-or-less regular "TM brain storming pizza lunch appointment" with Robert (Cerny), keeping my head spinning with ideas for days. And just earlier I was passing by CatBert's office.
He was lazily typing on his CatBook:
Look what I have done with my language TempleScript!
Actually TempleScript was our idea, but CatBert had started to take ownership.
Eating Your Own CatFood
His screen showed:
This is a complete web application written in TempleScript!
[Beware: Topic Maps ahead.]
Once you reach a certain age, you seriously ask yourself whether this has been be all: wealth, fame and many beautiful women.
It is the time when you look for a more integrated meaning in the universe. A meaning which transcends all levels of abstraction. And a processing model which gets rid of the silly separation between programming language and semantic data store with its static knowledge.
As I do not have the time to track this down properly, I simply take this opportunity to remove the complete TMQL support, just to factor this into my private implementation.
Version 1.46 is on its way into CPAN.
Ever since I met Jan Schreiber in Oslo a while back I had this itch that someone should write a C library for TMRM. Not only to host maps in proxy form, but more importantly to have a fast evaluation mechanism for myTMQL path expressions.
I was waiting for an opportunity to pack this into one of the paid projects, but that opportunity never arose.
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.
One other thing to get rid of is my ISO involvement.
When I got interested in Topic Maps in 2000/2001 I was quickly sucked into this circle of standardization. First only by providing intense feedback as developer on the SC34/WG3 mailing list, then also by participating in meetings all over the world.
Against popular belief these meetings were neither boring nor brutally controversial. Except maybe 2003 when the Ontopian and the Newcombian church were arguing about the virginity of Mary, i.e.
Every now and then I see typical stack diagrams depicting the standards landscape in TM and in RDF land.
While the relationship between TMRM and TMDM is mostly represented correctly, that is, that TMDM constructs can be couched in terms provided by TMRM, the rest of the usual diagrams does not reflect my understanding.
We have also fixed many small editorial problems and also removed all tracers, i.e. intentional mistakes which help checking whether someone actually has read the document.
Just to give people an estimate about the amount of effort: in this year I alone spent 3 weeks on TMQL, something which would not be possible if \
(Followup to IX)
While there will always be scenarios where you will appreciate the genericity and flexibility in terms of synchronisation which comes with using traits, in many cases the problem you need to solve is much simpler.
Maybe you just have a map in a CTM file and every time the program starts, map content should be read from that file. Or maybe your program probes a database at regular intervals and creates topic map content from it. Which should be finally copied into an XTM file. Or maybe you want both, i.e.
Specs and stuff.
Finally I found the time (read motivation) to update the TMQL issues list with
- the decisions post Leipzig 2007
- LMGs newly identified issues
- my elaborations on these issues, pre Oslo 2008
- the discussions and decisions in Oslo 2008, and
- decisions I made for the remaining open issues (as requested by the convener)
Maybe you have time to glimpse over these and point out existing oversights. I'll wait for some
Triggered by the TMQL tutorial I gave before the Oslo conference I have updated both documents
- TMQL Language (and still in flux)
They are both relative to TMQL 2007-07-13.
- I still owe you all an update of the TMQL issue list to manifest the decisions from Oslo. This will follow next.
- In June these issues must have made it into the TMQL spec.
- Maybe someone would want to try how the spec
One of the TMQL issues raises the question why there is no != operator when there is a == comparison.
In the following my attempt to explain the reasoning behind that decision. As always, feel free to comment.
Let us look at the simple query expression
$p / shoesize >= 42
Apart from trying to solve the answer to Life, the Universe, and Everything \