Logical constraints in TM (Re: [topicmaps-comment] TAO vs. ERA)

[Bernard Vatant <bernard.vatant@mondeca.com>]

Lars Marius, Tom

I think we drifted from the original thread to a wide new one, the question of logical
constraints in TM.

TP
> | Except I'm not sure if that strictly applies to multiple
> | inheritance, and I'm not sure if the standard class-subclass PSI
> | includes multiple inheritance.

LMG
> Multiple inheritance does not change anything in this respect. As for
> what the PSI supports the standard is silent about it, so it seems
> reasonable to assume that MI is allowed.

TP
> | In fact, there seem to be quite a few fine points about
> | subclass-hood;

LMG
> That is true, and we haven't considered those sufficiently. Are loops
> of subclassing associations allowed? If so, what are the consequences?
> If not, what is the rationale?

Those questions all boil down to the open question of how to express onto-logical
constraints in topic maps. We have so far no way to check such inconsistencies as
classification loops, no more indeed than to set and apply any other consistency or
inference rule. That is the reason why AI people are so skeptical about topic maps,
because they doubt that the underlying logical model can be clarified and extended to
include needed consistency and inference rules. Setting rules for logical consistency of
all associations in a topic map, not to speak about infering new associations from the
existing ones, seems way more complex than doing the same for binary hierarchical
relations of ontologies like class/instance and class/subclass.

Either we tackle that challenging issue as a whole, and IMO it's a task compared to which
setting XTM syntax will appear as a walkover, either we let implementors develop
proprietary and opportunist various solutions to implement rules for particular
associations, corresponding to whatever they consider relevant : check (or not) for loops
in classifications, allow (or not) multiple inheritance but declare inconsistency of
certain types, constrain (or not) type of topics playing a given role, e.g. (rolespec, X,
employee) => (topictype, X, people), set and check cardinality of members ... whatever ...
and so much for interoperability.

Suggestions ?

Bernard