[topicmapmail] tolog vs. TMQL - TMQL in general

[Robert Barta]

On Wed, Jul 01, 2009 at 11:31:16PM +1000, Alexander Johannesen wrote:
> Rani Pinchuk<rani.pinchuk at spaceapplications.com> wrote:

> >> There are many symbols that are too Perl-like
> 
> Not that they are too Perl-like (there's more than Perl who use a lot
> of similar notation, including PHP, XSLT, REGEX, etc.) but that they
> are too many; / vs. \, -> vs. ~~>, - vs. --, and so on. Let's just
> peak at a good one ;
> 
>    // person -- // evildoer
> 
> Coming from XPath this kinda makes a lot of sense (although I'd write
> it "//person -- //evildoer"), ....

.... which would be valid too ....

> but why -- and not -?

- is the arithmetic difference, so between decimal literals (numbers).

-- is the multiset difference, so between two sequences of tuples

> Or why not use
> "//person not //evildoer" as we're dealing with sets anyways?

One thing might be several times in such a sequence, so a multiset.

And things in a sequence might be ordered. So the -- indicates clearly
what happens. And there are not many of these things

  -- difference
  ++ adding of sequences
  == intersection of sequences

Over and out.

> (Maybe you can do this last one ... it's a big spec, and maybe I
> haven't found it yet :)

No, you can't :-) But the closest to that would be

  //person [ not . == // evildoer ]

(persons which are not instances of evildoers)

> >> The atomification and the concept of scheduling for [it] is very confusing
> 
> Why can't we cut out the concept of atoms, and just call them data
> types? We're even pointing to XSD for it, so surely keeping the lingo
> in sync will help understanding, and I don't see why we need atoms,

It would make the language rather impractical without the possibility
to create and compare to literals (integers, strings, dates, ...).

> As with Auto-Atomification, I don't actually understand why the
> process has to be postponed. Some examples would be great.

At

  http://kill.devc.at/system/files/language.html#id2479765

there is a lengthy background explanation why this was chosen.

> Has this got to do with serialization of result fragments?

Yes, among other things occurrences and names should be converted by
default into their literal values. Nota bene: by default.

> >> there is no "occurrence" axis while there is for example "players" axis or "scope" axis
> 
> If you're marrying the TMDM, you shouldn't fool around with other
> models, I'd say. But the closest thing to a value in the TMQL is the
> characteristics. I don't like them, though, as they take us back to
> early Topic Maps before the TMDM (as I recall).

The "characteristics" axes is simply a synthetic axes covering names
and occurrences. All in one go. Because, seriously, there is not much
difference between them anymore, right?

It is synthetic in the same way as "types" is synthetic. But I doubt
you want to miss _that_ axis, do you? :-)

> >> The traverse and the players axes are complex
> 
> I can see their usefulness, but their notation and perceived knowledge
> is a bit daunting at times, especially in more complex maps, but I
> can't help finding the traverse axis a bit sexy, though. If the
> direction notation could be made simpler, this in itself is a killer
> feature of the language.

The traversal and the role playing axes have about the same complexity
as in TOMA, I'd say from the examples I have seen so far. There is
less syntax normally in TMQL. At least it appears to me, maybe Rani
shows a counterexample.

> Ok, I'm off to bed. I'll stop whinging and try to be more helpful.
> I've started to write up my own examples of my own query language
> (which is by far closer to SQL and the spirit of it) which I've used
> for a few years, but not sure if that's any helpful at all in the
> uc-solutions document?

I have been looking for years for a volunteer. :-))) So no bedtime
for you yet!

\rho