[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
node.
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).
<snip>
> > [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
http://mathworld.wolfram.com/SetTheory.html).
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
sets?).
[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.
---------------------------------------------------------------------------