[topicmapmail] How do you deal with (lack of) association templates ?

[Lars Marius Garshol]

* Bernard Vatant
|
| For a paper I intend to present in Baltimore XML 2002, I would like
| to make a liitle review of how TM thinkers and developers deal
| currently with association templates - or rather with lack of any
| standard for that matter.

When you say "association templates" it is not clear what you mean, in
the sense that it's not clear what problem you think "association
templates" solve.
 
| To set the problem, let's take an example. Topic Maps A, B, C
| declare in the same scope "employment" associations
| 
| Topic Map A employment
| -- "employer" : X
| -- "employee" : Y
| 
| Topic Map B employment
| -- "employer" : X
| -- "employee" : Z
| 
| Topic Map C employment
| -- "company" : X
| -- "employee" : Y
| 
| Topic Map D employment
| -- "company" : X
| -- "CTO" : Y
| -- "consultant" : Z
| 
| "employment", "employee" and "company" are defined using the same
| PSI respectively.

Do you mean that these topics have the same PSI in the different topic
maps, so that upon merging they become the same topics? (I thought for
a while that 
 
| What is the result of merging of A and B ? How many associations?

This is described both in XTM 1.0, Annex F, and in the Standard
Application Model. Are you asking how to interpret those, or is there
something more to your question that I don't grasp?

The two associations are not equal, since the last role player is
different (assuming the two X-es share something that makes them
merge), so there will be two associations.

| Idem for A and C, then A and B and C ...

In none of these cases will any of the associations be removed.
 
| What process would you imagine or have you already figured to get
| rid of redundancy and reduce the number of associations and roles in
| the merged maps to the minimum in such cases?

Well, Bernard, you have to distinguish between what the standard
requires, and what an application can do to help users. The first you
must do, and everyone must do it the same way. The second you can do,
provided the user asks you to (and perhaps even provides you with
extra information).

I would deal with this as follows:

 - in the cases A-B, A-C, and B-C it is clear that the associations
   have the same structure, so that we should afterwards end up with
   two associations:

     employment(X : employer, Y : employee)
     employment(X : employer, Z : employee)

   You'd have to explicitly assert that "company" and "employer" are
   the same thing, and perhaps remove the name "company" from the
   merged topic, but that's easy.

 - D is different, and clearly requires structural transformations.
   Our goal is to let the query language deal with that, but for now
   we would use the API to implement the transformation. It's quite
   easy, actually.

Of course, this may not be at all appropriate for what you are trying
to do, since much of it depends on context, but given what you said,
and no further complications, this is what I'd do.

I would not expect to be able to do this automatically, without any
form of human intervention except where the standard lets you do that,
unless you have safe heuristics you can apply (like the TNC), which
you usually don't.

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