[sc34wg3] RM4TM issue : is role player always a set?

Sam Hunting sc34wg3@isotopicmaps.org
Sat, 23 Nov 2002 00:51:16 -0500 (EST)

In some sense, this title is a misnomer. A role player is always a

Of course, the subject of node N may be a set (for example, the node(s)
that play the set-member role in the assertion(s) of type set_set-member
where node N plays the set role).


> > [Graham Moore]
> > > I appreciate that RM does not subscribe to any
> > > mathematical set model ...

> >[Bernard Vatant] 
> > Why so? My maths background tends to make me disagree
> > with that.  I would like the RM to stand on a strong
> > mathematical model, grounded in set theory.  That is
> > the aim of the HG4TM proposal (see previous message)

We discussing, I think, a point where it is going to be "tricky" (as Lars
says) to draw the line between SAM and RM.

On the one hand, the RM clearly uses the *concept* of set -- but without
(so far) a mathematical definition of it.

On the other hand, the SAM (at least in discussion, uses the *term* set
in a non-mathematical sense -- for example, it speaks of sets as having
duplicate members.

On the third hand, "grounded in set theory" means "grounded in set
theory" means "grounded in a *particular* set theory." (see

I worry that by blessing a particular set theory in the RM, we would
foreclose some options that would be useful to us in the future (fuzzy

[Note also Bernard's careful comma, "mathematical model<EM>,</EM> grounded
in set theory." Meaning that a mathematical model (if any) would need to
support set theory, wihtout being necessarily equal to such a theory.]

Clearly, it would be possible to standardize an assertion type for
set/set member relationships that embodied a particular set theory and
express that (I "assert") in RM4TM terms for applications. I don't think
it should be normative, whether it goes in the RM or the SAM.

As Lars says, "tricky" ...

[Steve Newcomb]
> The RM4TM's attitude is, "RM4TM doesn't know about
> sets.  TM Applications define everything about sets:
> what a set is, how sets get their property values, what
> those values are, what's allowed to be a member of what
> kind of set, etc. etc."

Stve, this is a little vehement, I think. RM4TM uses the word "set", and
presumably has a concept in mind. Does the word need to go in the
Definitions section? Or is the meaning "obvious," in which case (Martin
Bryan will correct me here) it would *not* need to go in the Definitions?

> > > ... but i wonder about when do individuals become sets?
> RM4TM says, "I don't know.  TM Applications decide
> everything about sets.  If, for a TM Application, the
> idea of 'setness' goes to the heart of what a subject
> is, that's fine with RM4TM, because RM4TM doesn't know
> what a subject is, either."

Steve, I think again that this is too vehement. I don't know what "decide
everything" means. Clause 5 says what applications do, and whatever that
is, it isn't equal to "decide everything."

> > Hmm. Strange question indeed. Individuals do not
> > "become" sets.  As I understand it, in RM4TM, it
> > would be consistent for the role player to be
> > *always* a set, including the empty set, or a set
> > with a single element.
> That's for the TM Application to define.  RM4TM does
> not know about sets.  Sets are not an issue for RM4TM,
> and neither is "what's a subject?".  
> The ontology defined by a TM Application can *even*
> decide that there are no subjects that are not sets.
> Personally, I think that's a very extreme position.  I
> think it pollutes and colors the semantic space of the
> TM Application very severely, and I see no point in it
> (but maybe that's because you, Bernard, know something
> that I don't know).  I would hate to see the Standard
> Application take that position.  Why shouldn't a role
> player be allowed to be an individual subject, rather
> than a set of subjects with only one member?  For me,
> they are two different subjects.

As (in my own way) an implementor, I hate this, because of the lack of
symmetry between individuals and sets of one member. But when I think
about whether an individual qua indivuidual is the same subject, or a
different subject from an individual as a member of a set, I am forced to
agree that indeed there are two subjects (unless an application defines
them to be otherwise....). ["I am me! I am not the set of one member that
contains me!"]

> In a given TM Application, assertion type definitions
> may expect sets as the players of certain role types,
> while sets may *not* be expected as the role players of
> other role types.  For still other role types, both
> sets and non-sets may be expected as role players.
> This is not a problem.  It's a strength; RM4TM allows
> TM Applications to define their semantics freely.
> I'm trying to see this problem from your (Bernard's)
> perspective.  I'm thinking that you feel unhappy
> because, under the RM4TM model, you feel you are not
> allowed to be the father of each of your children
> individually, but instead you must be the father of a
> set of children.  You are only *indirectly*, through
> the set-making mechanism, allowed to be the father of
> each individual child.
> Well, if you want to represent your fatherhood of
> each child individually, then do so!  Make a separate
> father-child assertion for each of your relationships
> with your children.
> Or, if you insist on using a single assertion to
> express your fatherhood of all your children
> collectively, then do that!  First, represent your
> children collectively, as a set, and then express your
> fatherhood of that set.
> Nothing in the RM4TM prevents you from doing either
> thing, or both things at once.  They are two different
> graph structures, that's all.  And graph structures
> have exactly the semantics that their governing TM
> Applications define them to have, no more and no less.
> Inherently, as far as RM4TM is concerned, assertions
> and constellations of assertions have *no inherent
> significance whatsoever*.  It's only in the context of
> a TM Application definition that there's any
> significance, and that significance is *only what the
> TM Application definition defines it to be*.

I am not sure what "constellations of assertions" means. I think
constellation = set of stars = set of nodes, but that is clearly not what
you mean.
> Therefore, it is really true that your relationship
> with your children is not necessarily more distant if
> you represent your relationship with them collectively
> (way #1), than it is if you represent each relationship
> individually and directly (way #2):
>   (way #1: a set of direct assertions between you and
>   each child)
>   (way #2: a single assertion between you and the set
>   of your children, each one of which has an asserted
>   membership in that set)
> Either way, the TM Application defines the semantics of
> *all* of the assertion types.  It defines *all* of the
> properties and property values of each node.  The
> effect on the values of the properties of the "Bernard"
> node can be defined by the TM Application in such a way
> as to be *identical*.  Or, *different*.
> So, please don't assume that the assertion structures
> -- the situations of nodes -- have inherent semantics
> in the draft RM4TM.  They don't.  Constellations of
> assertions mean no more and no less than the TM
> Application's definition says that they mean.  If you
> don't like the idea of relating to your children as a
> set, then define the semantics in such a way as to
> ignore the existence of the sets entirely.  Under
> RM4TM, you can do that!
> RM4TM only tries to make sure that the Subject Location
> Uniqueness Objective is not violated.  It can't prevent
> such violations if it doesn't have rules that require
> TM Applications to be expressed within a graph
> discipline that prevents such violations.  But, at the
> same time, it doesn't have any built-in assumptions
> about graph structures (constellations of assertions).
> > > I'm not sure I found it but if I have two
> > > assertions in different maps where:
> > > graham worksfor empolis gmbh
> > > graham worksfor empolis uk
> > The role players of the "employer" role should be
> > respectively in that case {empolis gmbh} and {empolis
> > uk}
> > > and I merge them what happens?
> > 
> > The new role player is the reunion of the two sets.
> Maybe, or maybe not.  It depends on the situation
> features, SIDP values, and merging rules defined by the
> TM Application.
> > > is it now true that
> > > graham worksfor [empolis gmbh, empolis uk]
> > 
> > IMO yes, with correct set notation please :))
> > {empolis gmbh, empolis uk}
> > 
> > > How does this differ from the example bernard gave regarding his set of children?
> > Apparently no difference. I have to be resigned to be
> > the father of a set of children.  <sigh/>
> No.  Under RM4TM, you only have to be resigned to using
> a certain graph idiom (the 8 Forms of Connectedness).
> Everything else is up to the TM Application's
> definition.
> > That is the way I understand the logic of RM4TM. But
> > if it is, we need a specific representation of the
> > set-member relationship.
> Now, here, I agree with you, Bernard!  It's something I
> think the SAM cannot avoid doing.  And, maybe, the SAM
> will define different *kinds* of sets, too.  I don't
> know.  (I'm not proposing such a thing; I'm merely
> recognizing the possibility.  I tend to think we'd do
> better to define a single, totally generalized
> "set-member" assertion type.)

If such a thing is possible. Here, possibly, the academics can help ;-)

> > Otherwise, what are the role players in the
> > set-member assertion? We have a recursivity problem
> > here ...
> How is there a recursivity problem?  Can't a set be
> a set of sets?  
> -- Steve
> Steven R. Newcomb, Consultant
> srn@coolheads.com
> Coolheads Consulting
> http://www.coolheads.com
> voice: +1 972 359 8160
> fax:   +1 972 359 0270
> 1527 Northaven Drive
> Allen, Texas 75002-1648 USA
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

Sam Hunting
eTopicality, Inc.

"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.