TMQL and the Curse of TMDM
One of the features of Topic Maps, specifically of TMDM, is to offer a wide variety to express subject-related information and relationships. Alone for connecting information you have full-blown associations, specialized ones called occurrences and even more specialized ones called names. And then you have all the topic identification, reification stuff and other warts (which shall better not be mentioned here).
This is all in sharp contrast with RDF, which reduces all into one soup of triples. But this zoo of items in TMDM and the multitude of navigational axes is also its curse. All languages, specifically CTM and TMQL, have to deal with this and they struggle (a) to keep the syntactic noise low, but (b) still to offer the full range of navigational options.
While TMQL already has a numerous shortcuts for navigation I was thinking about the idea raised in Leipzig last year to drive this further.
Consider the innocent-looking association
To find rho's employment, the canonical way would be to write:
The first navigation step would lead to all associations where rho is playing the role employee. That list of association is then filtered to those only of type employment. From the remaining ones we navigate along the employer player axis.
Pragmatically, people will omit the type checking, especially if the modelling is proper and the association type itself does not add much:
That is not bad, but it was proposed to shorten this further, say (without paying too much respect to the symbols themselves) to
with obviously using the association type as a handle to control which way to move.
So, what would be the precise semantics of this, i.e what are exactly the results to be expected?
One alternative would be to say
find all associations of type employment and return all playing topics.
In the example it would return arcs and rho itself (!). It would allow a very efficient implementation as a TMQL processor would not need to memorize from where it had entered the association. But it is not exactly intuitive, especially when navigating further:
Another more intuitive way would be to define
find all associations of type employment and return all playing topics, except the one we started from.
That would remove rho from the list, but necessitates the processor to keep book on that incoming topic. And it is not as intuitive as one might think, if you consider the association
and the query
Is b included in the result, or only c?
If not, then how would it be possible to reach that other b, as it is a valid solution? But if b were in the result list, then a processor must not only keep track of the starting topic, but actually also the particular role.
The current TMQL semantics (and actually TMRM) has no vehicle for expressing this, as association role items have never been needed before. And if these were to be reintroduced into TMQL just to make the above shortcut work, the penalty for all this would be additional navigation axes for association roles. And maybe much more complexity in the mapping to TMRM.
Work supported by the Austrian Research Centers.