TopicMaps

Controlling What is Returned < TMQL Introduction < < Home

Controlling What is Returned

In the SELECT clauses we have used so far, we asked for whole topics. Any query processor will hand over a complete topic data structure (most probably according to TMDM) into the application. If an application were interested, say, only in the name of such a topic, it would have to use some API outside the scope of TMQL to navigate to that name.

To let the TMQL processor do the work, we can tweak the SELECT clause by adding a path expression:

select $album / name
where
   $album isa album

Now the processor will do the navigation for us, as we requested with / name to find all the names for the any thing bound to $album. It also does here something not obvious: It not only finds the name characteristics, i.e. the structures holding the string value for the name together with a scope and a type; it also reduces such a structure into its string value, which is exactly what the calling application will see.

This process of converting a characteristics (be it a name or an occurrence) into a string is called atomification, as literals as numbers, strings, etc. are referred to as atoms. In most cases, this is highly convenient, in others this is not.

Generally, a topic can have any number of names―all with different type or scope―, so we actually would get a whole list of names for each individual album. If we were not interested in all names, but only in those in, say, english (en), then we want to filter the characteristic first based on the scope and only then atomify the name:

select $album / name [ @ en ]
where
   $album isa album

If the processor would stupidly atomify all names to strings immediately, then the scope information would be lost, so filtering according to scope would not be possible. This then is not what happens. In fact, the processor will postpone the atomification until the end of the path expression. The precise rules are somewhat contrived. Later we will also see that we can also completely suppress this behavior, if it does not suit our purposes.

Path expressions are also a convenient way to impose a sorting order on the list of tuples we return:

select $album, $producer
where
   is-produced-by (production: $album, producer: $producer)
order by
   $album / name [ @ en ]

That way we get albums and their producer, but the whole list becomes a sequence sorted according to the english album title.

The ordering can also include more than one ordering criterion, like in

select $album, $producer
where
   is-produced-by (production: $album, producer: $producer)
order by
   $producer / name [ @ en ] desc, $album

Here we first sort the list of topic pairs according to the name of the producer. For demonstration only we choose descending ordering. More importantly though, for one specific producer name (in the english scope) we sort the sublist containing different albums according to the album's identifier. This may not by itself overly useful, but at least it takes care that the whole returned list always appears in the same order if we keep repeating the same query.

As you would expect, TMQL makes it possible to make the list of returned tuples unique and to select only slices out of the whole result set. It could look like this:

select $album
order by
   $album / name
unique offset 10 limit 20