[topicmapmail] multidirectional property of associationrole

[H. Holger Rath]

Hi,

Lars Marius Garshol wrote:
> =

> * 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. =


OK. But I and probably others don't know LTM that well that we were aware=

of this fact. =


> It's *not* the name. =


I just thought that the id automatically is used as name as well.

> The name is given
> using basenames, and that's where the semantics enter the picture.
> =

> So saying
> =

>   born-in([larsga] : baby, [l=E6rdal] : 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.

When we are talking about IDs I don't care how they look like. They
are for the computer - humans deal with names ;-)

> | 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.

I agree, see above.
 =

> | 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.

I agree. But I have the feeling that there are not only at least =

two solution proposals on the table (Ontopia's and empilis') but
also two approaches how to use the acrs.
 =

> | 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 look=
s like
> | this:
> |
> |   [born-in =3D "born in"
> |            =3D "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".

OK.

> * 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 > :-)

You're probably right -- I am not an language expert. But when you =

look at the internet (and that is probably the main market for topic maps=
) =

what is the mainly used language? And other issue: where are our =

(Ontopia's and empolis's) main markets? I would say that the approach =

of building SPO sentences work for 80% of assocs in the languages of our =

target markets. And the remaining 20% are still douable - it is not =

perfect grammar but a 'regular' user understands what you want to express=
=2E
So it is worth considering it, isn't it?

And for the other markets speaking non-indo-european languages? Well,
we still have assoc tye and role names, which could be rendered. Or using=

your approach. I hope at least this will work in the 'other' language =

families - but I am not sure because of lack of knowledge.
 =

> 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)

I see. I wasn't aware how you display n-ary assocs (with n > 2). =


Now we are getting to the point that we are proposing two different
approache what to label. You follow a different rendition 'approach' =

than we do. As you wrote above you define labels for every role for =

the 'complete' assoc and in this case your assoc name scoping solution =

scales - as your examples clearly shows. =


emplis follows a slightly different approach because we want to be able t=
o
label every possible role combination. And for this you have to scope the=
 =

role names. I assume you agree, that this technique makes
sense when this is the goal? Or do you have a better idea? I argued =

against your solution because I looked at it from the point of view of ou=
r =

approach. I hope you apologize.
 =

> The solution you propose requires n=B2 - n + 1 names, where n is the
> arity of the association. =


It is n*(n-1). But you're right. It 'explodes' when you have more than
three roles.

> For 4-ary associations that's 13 names. One
> of our customers uses 13-ary associations...

I assume this could be factorized down and you use this only for easier
maintance having everything in a single assoc. Could give us a hint
what is expressed with 13 role?

> | 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=3Do=
pera.xtm&id=3Dtosca >
> =

> The XTM example you gave was not complete, BTW.

Not complete in which sense (it was manually created)? I left out
the assoc instance - the example listed the type and role topics.
 =

> | 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.

Proposing TMCL was only an idea, because the verbs belong to the template=

part of an assoc in k42. But you are probably right that it
is not well positioned in the TMCL standard. What could be part of TMCL i=
s the
property that an assoc could be factorized as part of the cardinality
info about roles, which is somehow related to labelling arc because you
better know which arcs are really meaningful and which are not.
 =

> This is only needed for generic topic map navigation tools, which are
> only used for demo and debugging purposes anyway. =


When we generalize the problem we need something that allows us to
define how a rendition of a certain map looks like. A kind of TMSL
(Topic Map Style Language) with Formatting Objects (TMSL-FO) and a =

proper Transformation language (TMSL-T). But this is really
far down the road ... or anybody already working on this? The =

graph adressing, which will be certainly part of TMQL could be =

re-used in the TMSL-T as well as in TMCL. Might be a new requirement
for TMQL to define the graph addressing part somehow independent
from the rest in a way that it can be easily re-used by other TM =

standards.

> So it's not really a very big deal. An informal agreement would be =

> enough, I think. Or a joint technical report.

I like the TR idea. But I assume that we will only come to the point
that we independently describe our two appoaches and solutions. And
it makes sense because both are somehow useful. =


I would like to see that someone from Mondeca comments on this issue
as well.

Cheers,
--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