[topicmapmail] merge /solution / xtm-algebra

[Robert Barta]

On Mon, Feb 24, 2003 at 08:12:41PM +0100, Lars Marius Garshol wrote:
> 
> * Johannes Busse
> | I know many of the XTM-browsers are capable of merging xtm. But it
> | would be nice to have something like a xslt-stylesheet, which can be
> | included into a pipeline of other xslt-applications.
> 
> Merging is quite complicated, so I wouldn't try to do it with XSLT.
> Using a topic map engine is much better. As Kal says you can pump the
> result into XSLT if you want, though when we have TMQL using that
> directly will be enormously much better.
> 
> | (Is there a solution included within astma?)
> 
> AsTMa is a family of topic map languages, so they don't transform XTM
> in any way, though you can query XTM documents with AsTMa?.



[ Sorry, for the late reply, I had difficulties with mail. ]

1) AsTMa= is a notation like LTM or XTM.

2) AsTMa= is currently implemented in Perl XTM which also understands
   LTM and XTM. Regardless of the notation the processor there will
   merge as good as it can :-)

3) And yes, AsTMa? is _a plan_, I cannot offer any implementation _yet_.

> | - Is there some work on something like a xtm-algebra going on? 
> |   Should'nt we have operators (and semantic interpretations) like
> |   join, intersection, transitive hull and so on?
> 
> SAM provides a bit of that, and Robert Barta's work on tau algebra
> seems to be pretty much what you have in mind.

The goals of the tau-algebra are (a) to formalize static maps and
(b) to provide a logical framework for ontology engineering with
maps.

(a) is simply done by an algebra <M, {+/2, _|_/0}> which defines
    _declaratively_ how to merge maps. This part is also necessary
    to define some formal constructs which help me to define the
    semantics of AsTMa?.

    This will have to be aligned with SAM at some stage.

(b) is about maps, constraints and queries. The ultimate goal could
    be to write some expression like this

      Q * ( C * (M + O))

    What happens here is that a map M is enriched by O, an ontology.
    It contains new vocabulary but also application specific rules
    like "if someone is in a role manager within a "manages"
    association, then he is also an instance of a manager".

    The enriched version of M is then filtered by C which is a
    constraint. The filtered version is then queried by Q. Q
    transforms M into a result, which is again a map.

I hope this answers your question?

\rho