[topicmapmail] multidirectional property of associationrole

[Bernard Vatant]

BV
> | In Mondeca's engine, no association can't be created without
> | previous definition of a template, this template being itself an
> | association linking one "association type" and one or more "role type".

LMG
> Oh, so you don't follow the standard at all?
> In that case I guess it doesn't matter what you do.

Let me be clear about that once again, and hopefully once for all. I have heard recently,
e.g. in Orlando XML 2001, people saying things like "Ontopia and empolis are clearly
developing topic maps technology, but we don't really figure about Mondeca. What you do is
quite "mysterious". It seems that even for Lars Marius, there is still some "mystery"
hanging around there :))

Things are not that mysterious. Ontopia and empolis products use XTM syntax in their core
technology. That means that their engines really "process" and sort of "stand upon" XTM,
if this is the correct wording for it. Mondeca software does not use XTM at all in its
*core* technology, for two reasons at least.

1. The core technology architecture (Oracle data base + graph manager architecture) has
been developed more than two years ago, at a time where Mondeca was not even aware of
topic maps concepts, let alone XTM which was not developed at the time.

2. Mondeca has always considered afterwards XTM like *one among many* import-export
formats, but never the only one, nor even a necessary one in many customers applications.
We deal with various situations where the main user concern is not format
interoperability, but internal needs for managing legacy or publication. Input and output
of the data base can therefore be in all sorts of customized ad hoc XML formats, as long
as they can be expressed in terms of the generic mathematical structure the core
technology deals with, namely a labeled hypergraph. Could be RDF, whatever ...

For the sake of language interoperability, we call "topics" the hypergraph nodes, and
"associations" the hypergraph hyperedges. Nodes and hyperedges can be attached various
attributes, some of them can be interpreted as topic names, topic occurrences, or scopes.
We allow other interesting attributes like e.g. possible *time validation* of nodes and
edges, which have no satisfying simple equivalent in the TM model so far, that's why we
are proud enough to consider that our internal structure is more flexible and generic than
topic maps :))

Coming back to "association templates". To build and expand the graph needs using
predefined patterns. There is a primitive pattern, where all recursivity ends, which is
the "primitive association template", with two "primitive roles", namely "association
type" and "role type".

Thus when we want to create an "employment" association, we need first to create an
association template, built on the "primitive association template", with "employer" and
"employee" playing the role of "role type" and "employment" playing the role of
"association type".
For consistency, you have to declare also "employer" and "employee" as instances of role
type, and employment as instance of association type. This will not generally appear in an
exported topic map, but it would look like the following, if necessary. There again, this
TM structure is most of the time "virtual" in Mondeca engine.

<topicMap>
<topic>
    <instanceOf>
        <topicRef xlink:href="#association-type"/>
    </instanceOf>
    <baseName>
        <baseNameString>employment</baseNameString>
    </baseName>
</topic>
<topic>
    <instanceOf>
        <topicRef xlink:href="#role-type"/>
    </instanceOf>
    <baseName>
        <baseNameString>employer</baseNameString>
    </baseName>
</topic>
<topic>
    <instanceOf>
        <topicRef xlink:href="#role-type"/>
    </instanceOf>
    <baseName>
        <baseNameString>employee</baseNameString>
    </baseName>
</topic>
 ....
<!-- declaration of employment association template -->
<association>
    <instanceOf>
        <topicRef xlink:href="#association-template">
    </instanceOf>
    <member>
        <roleSpec>
            <topicRef xlink:href="#association-type"/>
        </roleSpec>
    <topicRef xlink:href="#employment"/>
    </member>
    <member>
        <roleSpec>
            <topicRef xlink:href="#role-type"/>
        </roleSpec>
        <topicRef xlink:href="#employer"/>
    </member>
    <member>
        <roleSpec>
            <topicRef xlink:href="#role-type"/>
        </roleSpec>
        <topicRef xlink:href="#employee"/>
     </member>
</association>
....
<!-- instance of employment association, following the declared template -->
<association>
    <instanceOf>
        <topicRef xlink:href="#employment">
    </instanceOf>
    <member>
        <roleSpec>
            <topicRef xlink:href="#employer"/>
        </roleSpec>
        <topicRef xlink:href="#mondeca"/>
    </member>
    <member>
        <roleSpec>
            <topicRef xlink:href="#employee"/>
        </roleSpec>
        <topicRef xlink:href="#bernard-vatant"/>
    </member>
 </association>
...
</topicMap>

The engine will not allow any association to be created without following some predefined
template, and will not allow an association declared "instance of employment" to use other
roles that "employer" or "employee". Those constraints are inherent to the graph
consistency. But they will not necessarily show in an XTM export. And BTW what is the way
in XTM to check for that kind of consistency? The association template issue is still open
in topic maps AFAIK , and I never understood why it was such of an issue, since the above
example shows a very natural way to deal with it.

But of course if you export all that stuff in any kind of publication format, you don't
generally need to show the "association template" or even any formal association structure
at all, and can decide that this association template will be rendered as
"Bernard Vatant" *is an employee of* "Mondeca", or "Mondeca" *employs* "Bernard Vatant",
or (Employs, Mondeca, Bernard Vatant) or a table with "Company" and "Employee" rows, or an
SVG graph vizualisation with some color/shape for every role, whatever ... just need a
good stylesheet for that matter.

Concerning names: Having some consistency in naming role types and association types is
just a conveniency for data base managers and authoring tool users. And of course for
exchanging XTM, and certainly published subjects are to set best practices there ... Using
substantive nouns seems generally to be the most fit for labeling non-directed edges. No
more no less.

Hope that helps - BTW Lars Marius, does that still mean for you that we "don't follow the
standard at all"?

Bernard