[sc34wg3] Review of N0393

[Jan Algermissen]

Dmitry wrote:
> 
> ----- Original Message -----
> From: "Jan Algermissen" <algermissen@acm.org>
> To: <sc34wg3@isotopicmaps.org>
> Sent: Saturday, April 26, 2003 3:14 PM
> Subject: Re: [sc34wg3] Review of N0393
> 
> > Lars Marius Garshol wrote:
> >
> > <snip />
> > > Now, as to why the thing is not implementable, and why it is not a
> > > technology, I will just scratch a little in the surface of it. There
> > > are many many more problems with the document than those I point to
> > > below,
> >
> > Well, in order to advance N0393 it would be usefull if you would
> > list as many problems as you see. Sure we will try fix the 'many
> > more problems' once you point them out.
> >
> 
> Jan,
> 
> I can suggest to discuss quite "simple" issue: difference in XTM/SAM
> association and RM/TMM assertion.
> 
> With this definition and restrictions:
> [parid0667] Within a single assertion, no two castings can cast role players
> in the same role.
> 
>             Note 7:  [parid0668] However, a set or group of subjects can be
> a subject, and it can therefore be a role player. The Topic Maps Model
> neither provides nor constrains set/group semantics; such semantics are
> defined entirely by TM Applications.
> 
> it is quite difficult to represent XTM/SAM association as assertion(s). 

Well, it propably is a bit difficult to understand, but it is not difficult
to do and since we are only talking about models it is totally open *how*
the representation is done inside an implementation.

> My
> suggestion: RM/TMM should define STANDARD way to represent set of topics
> with kind of enumeration constract. In this case RM/TMM  assertion will
> provide a "good basis" for representing
> XTM/SAM associations.

That would require to include the notion of setness in the TMM and we
choose not to do so. We wanted to exclude everything that is not needed at
the TMM level. Suppose you have a domain that does never use multiple
players of a single role, then you don;t have the burdon of bothering
with setness.


> 
> Alternative is to allow several players of the same role but, personally, I
> like more first idea.
> 
> I am just wondering what was behind [parid0667] and [parid0668].

It is a matter of how a given real world relationship is understood
and thus modeled as a topic map.

Suppose you have a soccer team and two trainers. There are two different
ways to model this:


a) there are two distinct associations, in which the team plays the role
   team and each trainer plays the role trainer.

b) there is a single assertion in which the team plays the role team
   and the trainers play the role trainer.

Modeling approach a) emphazises the understanding that the trainerships
of both trainers are independent. If one trainer calls in sick, one
association is 'broken' while the other is unaffected. Meaning that the
team can still be trained.

Approach b) emphasises the togetherness (the setness) of the two trainers,
one trainer cannot call in sick without the whole association being
broken. It is the set of trainers that plays the role, not each trainer
independently.

Thus, if there are multiple players of a single role in an association
(assertion) it is the set that plays the role.

In our understanding, such a set is itself a subject (after all it plays
the role) and thus there has to be a single topic that surrogates that
set. The fact that the two trainers are members of that set is to be
modeled with two set-member assertions.


To say all this the other way round:

If I choose approach a) I am clearly interested in each trainer
as an individual trainer. If I choose b) it is the set that I am
interested in. TMM supports that because if you retrieve the player
of role trainer you get the set directly - there is no need to
gather other role players.

Seems awkward at first but once you think about it it is
clear (at least that was my experience).

Jan

P.S. Thanks to Kal who's reply to a question of me on
topicmapmail actually inspired me to this way of explaining
all this:

http://www.infoloom.com/pipermail/topicmapmail/2003q2/004627.html


> Dmitry
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org