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

[Steven R. Newcomb]

"Bernard Vatant" <bernard.vatant@mondeca.com> writes:

> A number of issues with RM4TM have been discussed
> lately in quite a disorder, and the threads have
> become very difficult to follow. So I will start a
> few threads corresponding to identified issues. This
> one is about role players as sets.

> I will start from concerns expressed by Graham, that
> do no seem to have been addressed so far.

> [Graham Moore]

> > I appreciate that RM does not subscribe to any
> > mathematical set model ...

> 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)

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."

> > ... 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."

> 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.

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*.

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.)

> 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