WIAWTD: Topic Maps Ontology Language (TMOL)

This is obviously in the What I always wanted to do rubric. So if you happen to be one of these bored multi-billionaires, or alternatively, a research director for a semantic services R&D department using Topic Maps - normally my readers fall broadly into these two categories - then maybe this is for you to consider.

In an earlier version of TMQL (not the one which is discussed for standardization now) we allowed for developers to define their own functions and their own predicates. For a function the idea was to look something like this

nr-albums isa tmql:function
  tmql:return: fn:length (// albums [ . <- opus -> author == $person ])

nr-albums would be the identifier of the function. (And you may note that functions would look like topics in a map. There was a plan to this madness.)

The body of the function would then simply be an occurrence of a certain type. In the above case the occurrence value is TMQL code itself and would compute the number of albums a certain $person would have authored in the queried map. Parameter handling would be implicit as it is clear from the context that $person is the only (free) variable here.

And a predicate would be based on a boolean expression:

has-created-indirect isa tmql:predicate
  tmql:where:
     has-created (creator: $creator, opus: $opus)
     |
     is-part-of  (member : $creator, whole: $group) &
     has-created (creator: $group,   opus : $opus)

Inside a TMQL expression you could then use your functions and your predicates, such as in

select $person
where
     $person isa person &
     $thing  isa album  &
     has-created-indirect (creator: $person, opus: $thing)

There were a lot of other magic things you could do.

Now, the SC34/WG3 group has decided against having functions and predicate definitions inside TMQL, the reasoning being that both actually define to a large extent the problem domain, i.e. are ontological committments, i.e. should be handled as part of an ontology definition. And that is better covered with a separate ontology definition language, maybe (or not) similar to what OWL does in interplay with SPARQL.

The more pragmatic reasoning was also that many applications actually do not need this ontological modelling (and the inferencing layer which is involved), and that coupling this inferencing with TMQL would severely limit the range of implementors.

But the problem still is on the table. Waiting for a beautiful mind to solve (and implement). And a multi-billionaire to fund.

Posted In