[topicmapmail] How do you deal with (lack of) association templates ?
Lars Marius Garshol
larsga@garshol.priv.no
02 Jul 2002 13:44:40 +0200
* Bernard Vatant
|
| Well ... suppose I got definitive top quality information about your
| tastes from some Barcelona bars :o)
Yes. Baiting with Belgian beer is best. :)
* Lars Marius Garshol
|
| 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.
* Bernard Vatant
|
| Yes. But I guess it would that separation would be expressed by
| specific templates such as "technical employment" "administrative
| employment" ...
That might be, or you might want to simply organize the "position"
topics. I would probably choose the latter.
* Lars Marius Garshol
|
| 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.
* Bernard Vatant
|
| 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.
Not really. You can still use binary associations, or, if you want,
you can use ternary associations, or you can even use two binary
associations if your data set allows that.
* Bernard Vatant
|
| 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)
You're not providing a lot of information here, Bernard. There would
be no merging in this case. The three associations are different, and
so they would remain separate.
* Lars Marius Garshol
|
| 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.
* Bernard Vatant
|
| 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.
How will it be an issue? What is the problem?
* Lars Marius Garshol
|
| <issue id="merge-use-of-schemas"> [...]
* Bernard Vatant
|
| Thanks for that. I agree with that expression of the issue.
Excellent. If you have an opinion on it (or background information),
let me know, and I will record it in the issues topic map.
<URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=merge-use-of-schemas >
| 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.
Please do. At the very least, it would be useful input to the TMCL
process.
| 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".
That's a good point. It might also be possible for users to specify
how to handle the templates, and use that to actually do the merging
correctly.
* Lars Marius Garshol
|
| Not sure exactly what you mean by this. NT is "narrower-term", right?
| Better known as subclass? :)
* Bernard Vatant
|
| Wrong. *Often mistaken for* subclass. You should learn the
| difference IMO :))
I know the difference. I just thought you might have used the wrong
name here. :)
>From your explanation of how you used it I agree that this is BT/NT,
and not superclass-subclass.
* Lars Marius Garshol
|
| Well, I would change my mind on that. It would make your life a lot
| easier.
* Bernard Vatant
|
| ??? Do you mean *you* would change *your* mind so that *my* life is
| made a lot easier? Just can't believe it !!
Then you should go back and re-parse, and the apparent contradiction
would resolve itself. :)
The sentence is meant to be read: "Well, if I were you I would change
my mind on that, because doing so would make my life (I'm still you) a
lot easier."
I agree it could have been written more clearly.
* Lars Marius Garshol
|
| 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.
* Bernard Vatant
|
| 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.
I agree that there may be different ways to model the same set of
associations, and that to have some way to do transformations in order
to achieve interoperability would be good.
Whether it really belongs in the SAM or not I am not sure. I guess it
depends what sort of solution we come up with.
--
Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC <URL: http://www.garshol.priv.no >