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.

Problem Statement

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

employment (employee: rho, employer: arcs) .

To find rho's employment, the canonical way would be to write:

rho <- employee [ ^ employment ] -> employer

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:

rho <- employee -> employer

Proposed Solutions

That is not bad, but it was proposed to shorten this further, say (without paying too much respect to the symbols themselves) to

rho <<- employment ->>

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:

rho <<- employment ->> / name

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

at (r1: b, r2: b, r3: c) .

and the query

b <<- at ->>

Is b included in the result, or only c?

The Dilemma

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.

Posted In

Path functions in TMQL

One of the ways to achieve RDF-like compactness is to allow "path" functions in TMQL.

path works-for
.<- employee [ ^ employment ] -> employer

will do the job.

Path expression: rho/works-for looks reasonably short.

These "path" functions can be created manually or automatically generated based on descriptions of associations.


Dmitry (not verified) | Mon, 02/18/2008 - 02:45

Re: Path functions in TMQL

One of the ways to achieve RDF-like compactness is to allow "path" functions in TMQL.

path works-for
   . <- employee [ ^ employment ] -> employer

Well, yes, tucking complexity into a function always works.

But in Oslo 2007 we have decided to have no functions in TMQL as these (and predicates btw) were considered to fit better into an ontology language. I still think that decision was the right one.

We could introduce light-weight functions, but personally I am reluctant to do so: Either do it properly or leave it, I would say.

Path expression: rho / works-for looks reasonably short.

It does, but insinuates that works-for becomes an occurrence. How this plays out with other path expressions would have to be investigated.

On the other hand, such path functions would allow one to define transitivity, simply by calling the function recursively.

But I still see too much domain-specific knowledge encoded here. Ceterum censeo, we need an ontology definition language.

rho | Mon, 02/18/2008 - 20:54