[topicmapmail] multidirectional property of associationrole
H. Holger Rath
H. Holger Rath" <holger.rath@empolis.com
Thu, 31 Jan 2002 07:45:22 +0100
Hi,
Steve Pepper wrote:
>
> At 10:08 30/01/02 -0600, Dan Wu wrote:
> >In the same paper, The TAO of Topic Maps,
> >that I was reading.
> >
> >On page 12, it argued that
> >"....associations are inherently multidirectional. In topic maps
> >it does not make sense to say that A is related to B but that
> >B is not related to A; If A is related to B, then B must, by definition,
> >be related to A...."
> >
> >For example, in the assocation born_in,
> >I can have an association born_in(John, Canadan) to indicate
> >that John was born in Canada.
> >
> >The association between John and Canada, expressed
> >in topic map as an association born_in(John, Canada)
> >is differnent than the association born_in(Canada, John).
>
> The answer to this is that the concept of "association roles" removes the
> need for directionality. Your examples are confusing because they are
> incomplete: the roles are not stated.
>
> born_in(John, Canada)
>
> is asserting that there is a relationship of type [born_in] between the
> topics [John] and [Canada], but it is not saying which topic plays which
> role in this association. To make a complete and meaningful association you
> need to state the roles. In LTM syntax you would express them like this:
>
> born_in( [John] : person, [Canada] : place )
>
> This says that the topic [John] plays the role "person" and the topic
> [Canada] plays the role "place". The same thing can be expressed as:
>
> born_in( [Canada] : place, [John] : person )
>
> So you see, there is no direction.
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 (see below
the subject-verb-object explanation) and should as such avoided. I teach
my topic map classes that using verbs for assoc types should be considered
as bad design - substantives/ nouns should be used instead. I know that
finding the right noun is more difficult (the English language helps here
more than fex. German) but it makes everything crystal clear.
> But there is an *impression* of direction, caused by your use of a *verb*
> to label the association type ("born in"). Transitive verbs are very useful
> for describing (binary) relationships because the subject-verb-object
> construct in English maps neatly to topic-association-topic, but they can
> be misleading precisely because the subject-verb-object construct (at least
> in English) has an order to it.
>
> So should you avoid verbs? I think not, provided you don't imply a
> directionality that is not there. I use them quite freely as the IDs of
> topics that type associations. However, I also use multiple names for such
> topics and tell my application to choose the most pertinent name based on
> the vantage point from which the association is viewed.
>
> To see how this works, go to http://www.ontopia.net/omnigator/ and look at
> the topic map "opera.xtm". Navigate via "composer" to the topic "Puccini".
> Note that his "born in" association with "Lucca" is labelled "born in".
> Click on "Lucca" and see how the *same association* is now labelled
> "birthplace of".
This brings us to the 'labeling of arcs' issue. 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.
Why? Because now you are serializing the association in a way that it
becomes readable for humans. And the human language (at least the languages
I know) are a sequence of words - with a beginning and an end of the sentence.
It makes sense to apply the subject-verb-object concept when rendering the
assoc.
> How is this done? Simple. The topic used to type the association looks like
> this:
>
> <topic id="born-in">
> <baseName>
> <baseNameString>born in</baseNameString>
> </baseName>
> <baseName>
> <scope><topicRef xlink:href="#place"/></scope>
> <baseNameString>birthplace of</baseNameString>
> </baseName>
> </topic>
>
> The default name used to label associations of this type is the one in the
> unconstrained scope ("born in"). However, there is another name, in the
> scope "place" that is used when the association is presented in the context
> (scope) of the topic playing the *role* of "place" in the association.
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! Why? In a ternary
or n-ary association you would like to use different labels when you 'look'
from one role to the other ones.
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
You might claim that never do this in one ternary assoc but in two
binary ones (factorizing the ternary one) and I agree that I would
do the same for this example as well. But information theory teaches us
that there are assocs which cannot be factorized without losing
information (Steve, you might remember a meeting with Prof. Breutmann
in Rimpar several years ago). Sorry, that I don't have an example
at hand (have to find one).
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. Here is the XTM code for the 'birth' assoc type and its roles:
<topic id="birth">
<baseName>
<baseNameString>birth</baseNameString>
</baseName>
</topic>
<topic id="place">
<baseName>
<baseNameString>place</baseNameString>
</baseName>
<baseName>
<scope>
<topicRef xlink:href="#birth"/>
<topicRef xlink:href="#person"/>
</scope>
<baseNameString>is birthplace of</baseNameString>
</baseName>
</topic>
<topic id="person">
<baseName>
<baseNameString>person</baseNameString>
</baseName>
<baseName>
<scope>
<topicRef xlink:href="#birth"/>
<topicRef xlink:href="#place"/>
</scope>
<baseNameString>is born in</baseNameString>
</baseName>
</topic>
We assign the labels as additional names to the role topic scoping it
with the assoc type and the target role. This makes it absolutely
clear when a label has to be used and we can add as many roles as we
like. If you want to try this in k42 (http://k42.empolis.co.uk/), which
fully supports this in its topic map editor and topic map viewer,
create a assoc template, name the labels, and export the topic map
to XTM. BTW: The commercial version of k42 contains a graphical view
of the topic map which also uses these labels to display the assocs
in a very compact way - because space is very limited on a computer screen.
Check the Star Tree demo on the k42 web site
(http://k42.empolis.co.uk/demo/demo.html), to see the graphical viewer.
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.
Hope this helps,
--Holger
--
Dr. H. Holger Rath
- Director Research & Development -
empolis * GmbH
Bertelsmann MOHN Media Group
Technologiepark Pav. 17
97222 Rimpar, Germany
phone : +49-172-66-90-427
fax : +49-9365-8062-250
<mailto:holger.rath@empolis.com>
http://www.empolis.com