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

[Bernard Vatant]

* Lars Marius Garshol
> Yeah, I'm sure you put bait on the hook especially suited to my tastes. :-)

Well ... suppose I got definitive top quality information about your tastes from some
Barcelona bars :o)

> Wish I knew how to make you bite on the "scope is union"/"scope is
> intersection" (term-scope-def) issue...

Done overthere ... you just had to let that bait rotten for a while ...

> | The use of identifying such a template would be to be able to merge
> | e.g.
> |
> | -- employment : employer (X), employee(Y)
> | -- employment : employer (X), employee(W, Z)
> |
> | with X having the same subjectID in the two associations
> | into the following
> |
> | -- employment : employer (X), employee(W, Y, Z)
>
> Well, the template you gave above doesn't give you enough information
> for you to be able to know that that is safe. You have to know that
> there will only ever be one "employment" association per "employer",
> and the template you gave doesn't tell you that.

Good point! I did not think about it, but I guess it was an implicit assumption - that has
to be explicited indeed.

> So doing such merging
> wouldn't be safe in this case, because for all the application knows
> it might well be that separation of the employees into two groups has
> some semantic significance.

Yes. But I guess it would that separation would be expressed by specific templates such as
"technical employment" "administrative employment" ...

> | Which is very natural. You welcome new members in your association,
> | you don't create a new one.
>
> I disagree completely. Binary associations are easier to work with,
> easier to optimize, and if you use them then this isn't a problem at
> all. It seems clear to me that each employee has a separate employment
> relationship to the employer, so there's no loss of information or
> abuse of semantics in doing this with binary associations. In those
> cases I very much prefer using binary associations, because it saves a
> whole lot of trouble.

Maybe you have arguments in the chosen example, because "employer" and "employee" have a
very broad semantic spectrum. But if you take narrower roles like say "CEO" or "CTO" or
whatever specific function, things are different.

> * Lars Marius Garshol
> |
> | 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.
>
> * Bernard Vatant
> |
> | That's what is annoying. So if you have 50 employees for the same
> | employer, gathered one by one in a workflow, you'll get 50
> | associations ... too bad.
>
> Well, it has to be that way, as long as the application doesn't have
> enough information to know that it is safe to do further
> transformation on the merged associations. In many cases it won't be
> safe. Applications that have enough information can of course do the
> extra transformations themselves.

OK. I agree there it's all a question of applications choice.

> I guess this raises the issue of the possible impact of schema
> information on merging rules. The SAM needs to be specified in a way
> that allows this to be done in a standardized way using TMCL, once
> that is ready. (I've now added this as an issue in the SAM document.)
>
> Personally, I would *want* to see 50 associations in this case, as I
> said above.

In this case maybe. But think about merging the folowing
-- employment : company (X), CEO (Y)
-- employment : company (X), CTO (Z)
-- employment : company (X), COO (W)

> * Lars Marius Garshol
> |
> | In none of these cases will any of the associations be removed.
>
> * Bernard Vatant
> |
> | That's the point. This is not scalable in a workflow environment.
> | The topic map will get rapidly cluttered with redundant information.
>
> This information is only redundant if you use n-ary associations in
> cases where you don't need to. That's one of several reasons not to do
> that. I fail to see any impact on scaling.

If you have n associations, you have to go through two associations to go from one
employee to another.
I consider it can be an issue.

> * Bernard Vatant
> |
> | Since there is nothing in the standard about it, I'm just curious to
> | know how applications and developers deal with it or at least think
> | about it ... hoping some day it moves up to a standard. That's my
> | point
>
> Ah, I see. I agree that this is a use case that it would be good for
> the topic map family of standards to support. This is what I put into
> the SAM document just now:

>   <issue id="merge-use-of-schemas">
>   <p>The presence of a TMCL schema may allow applications to improve
>   the result of merging topics/topic maps by providing enough
>   information to allow implementations to do additional
>   transformations and redundancy removal. How should the SAM
>   specification deal with this possibility?</p>
>   </issue>

Thanks for that. I agree with that expression of the issue.

> I think this belongs in the realm of TMCL, and that the SAM needs to
> be carefully specified in a way that does not keep TMCL from doing so
> when the time comes. I guess this is what you are hinting at by
> bringing association templates into the discussion, except that
> association templates are not really powerful enough to be of much
> help in these cases, not even the extended notation that you used
> above.

The notation was just "ad hoc" and I do not pretend it to be sustainable. Templates could
be expressed in XTM, using PSIs for role types and association types. I'll make
propositions for that in a not-too-far future. If templates are declared inside an XTM
topic map (or whatever TM syntax), it will be easy to check before merging if templates
are consistent in the to-be-merged maps and at least have a warning : "You can merge that
stuff, but the result will certainly be inconsistent". It boils down again to the notion
that syntactically valid merging does not mean semantically valid merging.
But you are certainly right that such pre-merging checking process belongs to TMCL realm.

> * Bernard Vatant
> |
> | Yes. Or given that "company" being NT for "employer", keep "company"
> | in the final association.
>
> Not sure exactly what you mean by this. NT is "narrower-term", right?

Right.

> Better known as subclass? :)

Wrong. *Often mistaken for* subclass. You should learn the difference IMO :))
Roles generally do not define classes, but they can be linked by broader-narrower
relationships in a thesaurus.

Ex: You play a "voting member" role in "PubSubj TC team" where I play the "chair" role.
And we exchange those roles when we shift to GeoLang TC.

In a thesaurus, you would have e.g.

BT: voting member
    NT : chair
    NT : secretary

This is a hierachy of roles, which does not define a class/subclass relationship, as above
example shows clearly.

> * Lars Marius Garshol
> |
> | - 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.
>
> * Bernard Vatant
> |
> | But there are so many ways to do it ... My point is: how would you
> | set some general rules for that?
>
> You mean, "I want a general rule that solves this for all topic maps"?
> If we can do that, that would be good. I'm not sure we can. however.
> *If* we can, TMCL seems to be the key to doing it.

No. Not for *all* topic maps and *any* kind of weird templates. I'm not *that* arrogant.
Simple and effective rules for frequent cases would be great.

> | Well. I really think about workflow and automatic process in a
> | closed environment, and yes with TNC applying <snip/>.

> Well, I would change my mind on that. It would make your life a lot easier.

??? Do you mean *you* would change *your* mind so that *my* life is made a lot easier?
Just can't believe it !!

> There *are* cases where n-ary associations are appropriate,
> but I think that in the cases where they are you will need information
> about the world being modelled in order to tell what association to
> put the role players in. In other words, the standard probably won't
> be able to help you with that.

It is not only a question of n-ary or binary associations. Whatever the reason you want to
do it, be it relevant or silly, the application model could say something about what to
do, how to process when similar templates are declared in two topic maps at the time of
merging, and you want to merge the associations following those templates. If we let that
to developers, it's clear that we can forget about interoperability in that domain.

Bernard

-------------------------------------------------------------------
Bernard Vatant
Consultant - Mondeca
www.mondeca.com
Chair - OASIS TM PubSubj Technical Committee
www.oasis-open.org/committees/tm-pubsubj/
-------------------------------------------------------------------