[topicmapmail] generate hierarchical GUIs from all transitive associations

[Bernard Vatant]

*Conal Tuohy

|Mark wrote:
|
|> A major mathematical tool/approach that TM can heavily
|> leverage is Set
|> Theory, as you know (just getting us on the same page). Topic
|> Map solutions
|> must deal with set theory because, in my opinion TMs ARE
|> sets.
|
|In the earlier thread about class-subclass and class-instance
relations, I
|was also inspired to dig out my old algebra text books. It seems to me
|useful to categorise associations in terms of the properties of binary
|relations, such as symmetry, anti-symmetry, transitivity, reflexivity,
etc.
|Transitivity at least is recognised in the XTM spec with a PSI:
|http://www.topicmaps.com/xtm/1.0/template.xtm#assoc-prop-transitive -
it's
|possible to annotate any association topic as having this property, and
|then
|use this knowledge e.g. in your UI: the issue that came up earlier, of
|selecting which associations should appear as a hierarchy in a UI,
|breadcrumbs, etc, can then be dealt with automatically: an association
type
|is suitable if it is transitive and hence represents some kind of
ordering.
|The class-subclass relation is just one such relation, and a UI could
|present several "genealogies" for a given topic; one for each such
|relation.

Two remarks from the maths teacher :)

1) The inference "is transitive and hence represents some kind of
ordering" is wrong if "some kind of ordering" means "an order relation".
Transitivity is not enough a property to be an order relation: you need
also reflexivity and antisymmetry. See last example below.

2) Even for true order relations, things are more complex. 
Order relations have not all the same flavor, even if they all share the
basic properties (reflexivity, transitivity, antisymmetry).

Class-subclass relation is strictly linked to (and in fact, derived
from) class-instance relation (which is not an order relation):

(A subclassOf B) <=> (forAll x) (x instanceOf A) => (x instanceOf B)

The same type of equivalence holds when replacing "class" and "instance"
by some isomorphic equivalents in context, e.g., "set" and "element",
"type" and "instance", "species" and "representative", "family" and
"member" ...

In that kind of relations, the UI at some point has to show the
instances (respectively: elements, representatives, members...)

But not *any* order relation have that kind of instance-foundation. If
you consider for example the "whole-part" relation, between topics
representing continuous physical objects (e.g. geographical areas) there
is no equivalent of instances. So that kind of order cannot be dealt
with, in the UI, the same way as "class-instance". 

Now for transitive relations which are not order. They are typically
derived from comparison of value of measurable attributes, like
"olderThan", greaterThan"... 

They can be defined as in the "broad" sense, e.g. (a olderThan b) is
taken to mean: "The age of a is greater than *or equal to* the age of b"

In that case, you get reflexivity: (forAll x) (x olderThan x)

But not antisymmetry - You can have:

(a olderThan b) and (b olderThan a) and (a and b are distinct)

In other words:  (a and b have the same age)

So, this is not and order relation, although it is transitive. The UI
may want something very different for that type of relation than for
class-subclass or whole-part, like showing together topics than share a
same property value, or topics with values in a given span, etc...

Bottom line: UI have to be grounded on more specific features than
simple generic ones like transitivity. In fact, you always end up
building UI adapted to your specific ontology features, including
association types and templates, occurrence types ... in a word, to some
kind of "TM schema". 

Otherwise, you get some kind of "ommnigator" which is known to be a very
rough UI - even if very useful for TM construction and validation.

Bernard

============================================
Bernard Vatant
Knowledge Engineering
Mondeca - www.mondeca.com
OASIS Published Subjects Technical Committee
www.oasis-open.org/committees/tm-pubsubj
============================================