TopicMaps

Predefined Datatypes and Functions < TMQL Introduction < < Home

Predefined Datatypes and Functions

Since the latests TMDM drafts include features to store arbitrary data (and not just text as in the original XTM-based standard drafts), TMQL has provisions for data. The obvious first thing to support is to denote constants; here TMQL borrows (stealing is such an ugly word) from RDF(S) notations:

select $person / name
where
   $person / age > "18"^^xsd:integer

This query will select names for everyone older than 18.

Now, writing integers, floats, or even dates and strings in this explicit form is somewhat clumsy. Therefore TMQL has adopted a few of these primitive types, specifically integers, decimals, dates, URIs and strings, all imported from the XSD (XML schema data types) namespace. Constants of these types can be written without the explicit typing fluff:

select $person / name
where
       $person / age  >  1           &
       $person / born >= 1962-06-06  &
   not ( $person / name     = "Bill Gates" |
         $person / homepage = http://he.is.so.good.to.us/ )

As a consequence, also necessary functions for these data types have been imported into TMQL and are part of the predefined environment. This includes also the comparison functions which we have used above. Actually, when writing a comparison like $person / age > 18, several things happen: first we extract the age occurrence from a person. This characteristic will then silently atomified to its value. If that value is already an integer, then it will be used as-is. Otherwise TMQL will try to convert it, which may only work if the value is a string with only digits in it. Then the two integers will be compared using the predefined function op:numeric-greater-than.

There is also another twist here: You may have noted that a path expression like $person / born may return more than one characteristic; or none, depending how many born occurrences actually exist for the given topic. The interpretation TMQL chooses here is exists semantics. TMQL will translate this to a more explicit

some $_16523 in $person / born 
    satisfy 
        op:dayTimeDuration-greater-than ($_16523, 1962-06-06)

whereby the variable $_16523 is internally generated. If the processor had access to a description of the queried map (the ontology) and if it could learn that there is always exactly one born property for every person, an optimizer could collapse the above SOME clause.