[topicmapmail] binary associatinons: Two roleSpecs or many more?

[Thomas B. Passin]

[Johannes Busse]>
>
> in defining an ontology I got the following
> question: I am wondering, how many roleSpecs can (or
> should be) "attached" to an association with *two*
> members: Two roleSpecs or many more?
> ...
> It seems to me that this often is a reminiscence to the
> database-notion of an relation, where the
> table headings are semantically not very interesting.
>

Actually, a row of data is called a "relation" in a relational database
theory.  It is more or less isomorphic to a TM association with one or more
roles.  The label of a column is equivalent to the label of the TM role.

> The ontology impregnated within the XMT-model for
> me seems to be semantically mor rich than the
> ontology of relational modeling. The nature of a
> link between two topics consists always of three
> elements: assoc, "left" role, "right" role.
>

An ontology is a special case, and you would expect just two roles for any
one association type - in fact, there is often  only one association type in
play,  parent-child or class-subclass kind of association.
>
>
> Iff this is right, there are several consequences:
>
> (1) The topic-view of an XTM-Browser should show
> not only associated topics, but also the attached
> roles *for each topic*. (To my knowledge eg. the
> omnigator does this not. Is this a feature or a
> lack of function?) - Do you know, where this
> slightly complex problem of visualisation is
> solved?
>

In my experiments I have found that displaying the role is often more useful
for a person (at least, for _me_!) than the association label (but sometimes
you need the label too, especially if there are more roles involved with the
assocation).  It seems that, if you know the role something is playing, that
gives you most of the information you need.  Of course, people are good at
inferring  missing information, much better than computers.


Using the notation (xxx) ==> association, and [xxx] ==> role, try this -

Tom -- (is employed by) -- Mitretek Systems

and

Tom -- [employer] -- Mitretek Systems

In the first, we have to infer two roles.  In the second, we infer one
association type and one role.  If the association type's template (in our
mind, I mean) is fairly unambiguous about its roles, then the second
inference would be very easy to make.  But either way works pretty well.

Now try this -

Tom -- (has personal info) -- Virginia
                                            -- 703 555-1212
                                            -- tpassin@comcast.net

versus -

Tom -- [location] -- Virginia
        -- [telephone] -- 703 555-1212
        -- [email] -- tpassin@comcast.net

With the role labels, I get more of the information I am interested in.  In
this example, I probably do not even care about the nature of the
association.

Now, for the sake of illustration, I have given my topics labels that are
the same as the data that they contain (presumably in an occurrence).  An
association is really more equivalent to a row in a "fact table" in a
so-called star schema (used in data warehouses), where every cell contains a
pointer (foreign key) to a table of information such as Person.  Still, with
good topic names, displaying the role label can be more useful to a person
than displaying the association label.

If you can have the same role name in more than one association type, you
may need the association label to distinguish them.  For example, in Steve
Pepper's Opera topic map, there are "born in" and "died in" associations,
and both of them use the role "place".  When you see a role "place"
associated with a person's name, you cannot tell whether that person died
there or was born there.

In such a case, I have found it useful to be able to switch quickly to
another view that shows more complete information, and I still like the view
with just the role.  Also, I find that I rarely need to see the role of the
topic I am focusing on ("Tom" in the example above) but just the other
roles.

> (3) an association can be seen as a "sparse"
> relation:
> - each row has indefinitely many columns, which
> - most of them are empty or "undefined", whereby
> - only very few of them are  used
> - these which are used have to be made explicit by
>   means of the roleSpec
>

Just so.

Cheers,

Tom P