[topicmapmail] multidirectional property of associationrole

Lars Marius Garshol larsga@garshol.priv.no
31 Jan 2002 18:55:21 +0100


* H. Holger Rath
| 
| Well, as Jan has already written in his reply, using a verb as a
| name for an association type/class is always 'implying' a direction

True, but you must keep in mind what we are talking about. Steve and I
gave LTM examples, and the "born-in" string that appeared there is
just the ID of the association. It's *not* the name. The name is given
using basenames, and that's where the semantics enter the picture.

So saying

  born-in([larsga] : baby, [lærdal] : birthplace)

is in my opinion perfectly OK. It does not in any way imply a
direction, simply because topic maps don't do that. The ID is just
chosen to make the LTM source file more readable, and doing the same
in an XTM file would be perfectly OK, since the ID has no semantics in
any case.

| I teach my topic map classes that using verbs for assoc types should
| be considered as bad design - substantives/ nouns should be used
| instead.

As the unscoped name of an association type, yes. As the ID, no.

| This brings us to the 'labeling of arcs' issue. 

It does, and I'm glad this is finally being discussed in the open. We
should thrash this out, and then just all use a single solution. It's
much better for all of us that way.

| As Steve writes, using verbs to label the arcs when you render
| (display) the information in the topic map (e.g., in HTML or in a
| graphical view) is where the verbs belong.

Exactly.

* Steve Pepper (translated into LTM)
|
| How is this done? Simple. The topic used to type the association looks like
| this:
| 
|   [born-in = "born in"
|            = "birthplace of" / place]
| 
| The default name used to label associations of this type is the one
| in the unconstrained scope ("born in").

And that one should probably be named "birthplace", since that's a
better name for the *association*. The "born in" name should have the
scope "baby".
 
* H. Holger Rath
|
| This is a nice approach to model the 'arc' labels of an assoc. But
| it has a big disadvantage: it works for binary assocs only! 

The opera topic map uses this for 4-ary associations, so this claim
comes as something of a surprise for us. :-)

| In a ternary or n-ary association you would like to use different
| labels when you 'look' from one role to the other ones.

Agreed.
 
| An example: If we add the third role 'date-of-birth' to the
| 'born-in' assoc the label 'birthplace of' would be used in both
| cases (place)->(person) and (place)->(date-of-birth) leading to
| sentences like:
| 
| 	Canada is birthplace of John
| 	Canada is birthplace of March 31 1966

Well, you can't reliably produce sentences in a generic topic map
navigation tool. You may get it to work in some cases in English, and
maybe even German, but for Japanese and other non-indo-european
languages it just won't work. (Try Kiwai, for example.  <URL:
http://www.krysstal.com/langfams.html > :-)

What we do is to always show this association from the point of view
of one of the players in the association. The name of the association
is chosen by using the association role type as the scope. This works
beautifully, as the table below shows.

  Current topic    |   Association title
  -----------------+---------------------
  John             |   Birth of
  Canada           |   Birthplace of
  March 31 1966    |   Birthdate of

And we achieve this by having only one name for the association, plus
one per association role. For n-ary associations we list each role in
the association, giving the player and association role type names for
each. So this association seen from John would look like so:

John
  birth of
    Canada (birthplace)
    March 31 1966 (birthdate)

The solution you propose requires n² - n + 1 names, where n is the
arity of the association. For 4-ary associations that's 13 names. One
of our customers uses 13-ary associations...

| Anyway, let's come back to the labeling problem. empolis thought
| about this and came up with a solution which looks similar to the
| Ontopia one but is not limited to binary assocs - it works for n-ary
| assocs as well.

As I've demonstrated our solution does in fact work for n-ary
associations. Study our online demo if you want to make sure. Look at
the opera 'Tosca', for example:

<URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=opera.xtm&id=tosca >

The XTM example you gave was not complete, BTW.

| A closing remark: ISO is working on a Topic Map Constraint Language,
| which will become the schema language for topic maps. I assume this
| concept of labeling arcs could go in there and that we have only one
| standardized solution afterwards.

What would it do in a constraint language? That is, how would it fit
into TMCL? I have problems seeing that.

This is only needed for generic topic map navigation tools, which are
only used for demo and debugging purposes anyway. So it's not really a
very big deal. An informal agreement would be enough, I think. Or a
joint technical report.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >