[sc34wg3] TMQL Issue: transitive closure

[Robert Barta]

And me again, but this time it's TMQL time:

  http://www.ontopia.net/tmwiki/topic.jsp?id=tmql-transitive-closure

I took the liberty to write my ponderings up in

  http://kill.devc.at/print/128

Reproduced below, only for the self-containment of this list. Feel
free to comment here or there.

\rho

----------------------------------------------------------------------

TMQL Issue: Reasoning Through the Backdoor?
 
While browsing through the current issues for TMQL [1] I came across
the one issue which describes a feature request to extend navigation
[2].  If I remember it correctly, this was thinking along the lines of
compactifying the current navigation syntax [3] 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 [4] (or
rather globbing [5]) 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
[6] 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 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 [7].

Links:
[1] http://www.ontopia.net/tmwiki/topic.jsp?id=tmql
 [2] http://www.ontopia.net/tmwiki/topic.jsp?id=tmql-transitive-closure
 [3] http://kill.devc.at/node/127
 [4] http://kill.devc.at/wiki/RexExp
 [5] http://en.wikipedia.org/wiki/Globbing
 [6] http://search.cpan.org/perldoc?TM::Graph
 [7] http://www.arcs.ac.at