[topicmapmail] merge /solution / xtm-algebra

[Kal Ahmed]

On Fri, 2003-02-21 at 16:34, Johannes Busse wrote:
> Hello XTM-Community,
> 
> how should we manage a set of Topic Maps we'd like to merge? 
> 
> I've had just an idea: lets construct a fuction xtm2xtm, which works
> als follows (I know: I'm ashame of the basic-like notion; but I ensure
> you: I've *not* used it for about 20 years :-)
> 
At least you didn't present your example in FORTH ;-)

> 
> 05 let be integer i = 1
> 
> 20 merge all XTM i+1, which are occurences 
>    of the occurence Type XTM within XTM i
> 
>    (hint: iff one of the XTM i is referencing itself by means of an
>    occurence, we have an self referencing function; otherwise, we have
>    a hierarchically function; in either case we should use a fixpoint
>    semantic to describe this function adequately)
> 
> 30 if (the cardinality?) of XTM i equals (the cardinality?) of XTM i+1 
>    then goto end
> 
> 40 increase i by 1; loop to 20
> 

If I remember my days of programming BASIC on the ZX Spectrum, it seems
to me that you are doing something like the processing of mergeMap and
external topic refs. In XTM, there are two ways in which an external
topic map can be required to be merged into a topic map being parsed:

1) by an explicit inclusion using the <mergeMap> element. I think that
this has the semantics you intend for your "occurrence Type XTM"

2) by the implicit inclusion of topics which are referenced from a
<topicRef> element. The <topicRef> can appear in a number of places -
inside the definition of a scope; as the type of another topic,
association or occurrence or as the <roleSpec> definition for an
association member. If this reference is to  a topic in an external
topic map, then by the rules of the XTM Processing Requirements, an
application *may* allow the user to choose to merge those external topic
maps into their topic map.

As for the actual algorithm, I think that you can make one small
simplification. Basically if you are dealing with topic maps as
addressable resources (e.g. as XTM, LTM or AsTMa files); then you can
maintain a list of the resource addresses you have parsed during your
processing, and only visit those references that you have not already
visited previously.

> 
> 
> The basic question:
> 
> - Has anybody had success yet with something like that? Or are there
>   serious arguments against it?
> 
> 
> The pragamtic question: 
> 
> - Which with tools would you perform this task? 
> 
> 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.
> (Is there a solution included within astma?)
> 

Within TM4J there are command line applications "Merge" and "Compress"
that will do this merge processing for you and produce XTM syntax output
which you could pipe into an XSLT engine.

> 
> The vision:
> 
> - 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?
> 

I think there are some operations which can be defined for topic maps.
Especially with regards to filtering and merging. For example:

1) Filter the topic map to leave only a specific ontology (type-based
filtering)

2) Filter the topic map to remove/retain only those characteristics
which are valid in a given context (scope-based filtering)

3) Filter the topic map to prune away all topics that are more than n
association "hops" away from topic X

I'm sure that there are more as well. It would be an intersting project
for someone to define a more complete set of such operators and to show
how such operators might be combined for practical purposes such as
presentation, reporting, and interchange.

Cheers,

Kal