TMQL Issue: Reasoning Through the Backdoor?

While browsing through the current issues for TMQL I came across the one issue which describes a feature request to extend navigation.

If I remember it correctly, this was thinking along the lines of compactifying the current navigation syntax and to take this further, say, by allowing

rho <<- is-located-in * ->>

Ignore the symbols, I just make them up as I go.

The * after the association type should tell a TMQL processor that it not only should navigate along that type, but that it should try to repeat this step any number of times and collect all results. Obviously this is ideal for association types which are transitive in nature, such as is-located-in.

You could take this scheme even further by allowing a RexExp (or rather globbing) style approach:

rho <<- is-affiliated
        is-part-of *
        is-located-in  ->>

The above would first check where rho is affiliated, in exactly one step. And then it would see whether this thing is part of anything bigger, and would follow this up as much as possible. For each of these bigger things found, it would check whether there is any location information.

You could so give |, * and + an obvious interpretation:

some_work <<- (is-responsible | has-adopted )+ ->>

In fact, I implemented such a functionality into my Perl TM package for a project last year:

@hull = $tm->frontier (\@start_lids, $path_spec)

This method computes a qualified hull, i.e. a list of all topics which are reachable from start_lids via a path specified by path_spec. The path specification is a (recursive) data structure, describing sequences, alternatives and repetition ..., all encoded as lists of lists.

Why not in TMQL?

What lets me hesitate to have this as such in TMQL is that it carries all the hallmarks of an adhoc-ish solution to add ontological information. If I write is-located-in * I basically tell the processor:

Please interpret is-located-in in a transitive way.

This is clearly ontological information and this involves (some) reasoning.

What I also would like to avoid is a situation where users, i.e. here programmers, hide ontological information inside a TMQL expression. Useful information - when manifested properly - could be used more effectively. For instance to optimize a TM store.

I am also concerned that such a backdoor reasoning feature cannot be captured with the current machinery which defines the formal TMQL semantics. That had been produced in a rather minimalistic way. Reasoning (even if only homeopathic) cannot be covered easily.

Conclusio

Absolute no argument that all the above is useful and practical. And I also cannot see why it would not work. But that could also be said about rules, functions, additional adhoc topics and associations.

My best bet is to move this functionality into an TMQL-intrinsic function. Then implementations can deal with it in a rather controllable way. Should later an ontology language arrive to express this in a more semantically relevant way, no harm, no foul.

Ceterum censeo lingua ontologica creandum esse.


Work supported by the Austrian Research Centers.

Posted In