[sc34wg3] Draft Reference Model
Jan Algermissen
sc34wg3@isotopicmaps.org
Mon, 18 Nov 2002 21:34:38 +0100
Bernard,
I think we must be careful not to confuse two different things:
1) The case of the relationship you have with your children, which are
in my understanding *several* distinct relationships of some type
at-parent-child.
2) Some sort of a family relationship where one person plays the role
mother, another plays the role father and several persons play the role
child (and those would be the "set of subjects that play the role child")
Back to your siblings example, or more general the issue of representing
non-directional relationships:
If I understand you correctly, and you are saying that the RM must allow
assertion with only a single role in order to model such relationships,
I think you are right.
Example:
"'Hot' and 'cold' are opposites"
This would be modeled in the graph like this:
x2
/
C-----R2
/
T1 A-----T2
| /
| R1 C-----R3
| | /
A-------C-------x1
\
C-----R3
\
A-----T2
\
C-----R2
\
x3
The nodes above represent the following subjects:
T1: the assertion type 'at-opposites'
R1: the role 'role-opposite'
x1: the players of the role-opposite ("The Opposites")
R2: the role 'role-setMember'
R3: the role 'role-set'
T2: the assertion type 'at-set-setMember'
x2: 'hot'
x3: 'cold'
I can't see how this could be modeled without allowing a single
membership in an assertion.
Does this answer your question, Bernard ?
Jan
Bernard Vatant wrote:
>
> Steve
>
> > [Bernard Vatant]
>
> > > > > 3.5.1.3 Well-formed node Case 3 ("a-node")
> > > > > 3.5.1.3.1.2 The node serves as the A endpoint of two or more AC arcs.
> >
> > > > Why "two or more"? There are many cases of assertions with a single role type (take
> > > > "sibling" for example)
>
> > We've had numerous discussions about this, and the
> > following viewpoint has (so far, anyway) prevailed
> > consistently:
>
> > A relationship *type* that has only one possible
> > membership isn't a type of relationship at all. In
> > an instance of such a relationship type, nothing can
> > have a relationship with anything else, by
> > definition, so it's not a relationship.
>
> As expressed before in answer to Sam, unless I miss something, how do I express
> sibling-ness or any other equivalence relationship if:
> 1. A single membership is not allowed.
> 2. Having two c-nodes of the same type in an assertion is not alllowed.
>
> > In the realm of syntax, however, it's frequently the
> > case that a link points somewhere else to establish a
> > relationship between the link and whatever the link
> > is pointing at ...
>
> I'm not sure to catch what you are speaking about here, Steve, but I guess it's not
> addressing my sibling-ness issue.
>
> > If a relationship type has two possible role types, and
> > an instance of that relationship type has a role player
> > for only one of the role types, that's OK. In fact,
> > it's a frequent state of affairs in the real world: the
> > relationship exists, and one of the role players
> > exists, but there's no role player for the other role.
> > The RM4TM has no problem with this.
>
> Neither have I. Having a casting as an empty slot waiting for the role player is frequent
> indeed. This non-issue has been raised by Marc on topicmapmail recently ...
>
> BV
> > > > I'm curious about the rationale making role type
> > > > mandatory and assertion type optional. (BTW both
> > > > are mandatory in Mondeca ITM)
> >
> > Here's the rationale (at least as I see it):
> >
> > (1) In the graph, all role types are mandatory because
> > without them, there's literally no way to tell
> > which role player is playing which role.
>
> True. That's why I always wondered why it is optional in XTM 1.0
>
> > (2) Assertion types *are* mandatory for all assertions
> > that determine the subjects of any of their role
> > players.
>
> Why those in particular? And what do you mean by "determine" ?
> I'm lost here ...
>
> > The RM4TM constrains the definitions of assertion
> > types: it requires them to say how the values of
> > the Subject Identity Discriminating Properties
> > (SIDPs) of their role-playing nodes are affected.
>
> That is a point I would like to see expanded in Baltimore.
> I think I miss the point at the moment ...
>
> > (3) Assertion types are *not* mandatory (but are still
> > a very good idea, I think) for assertions that
> > don't determine the subjects of their role players.
> > As far as the RM4TM is concerned, if an assertion
> > has no impact on the achievement of the Subject
> > Location Uniqueness Objective, it's not very
> > interesting to the RM4TM, and the RM4TM doesn't
> > care very much about it.
> >
> > There is one very interesting implication of an
> > assertion's being "untyped" (i.e., about the fact
> > that an assertion's type is unspecified): such
> > assertions can never merge, even if they have the
> > same role players playing the same role types.
> > This is because, if their types are unknown, it
> > cannot be known whether they are really the same.
>
> Yes indeed. And that looks to me more like poor modeling than anything else.
> I am curious to know of any serious TM application using untyped assertions.
> As said before, it is something completely forbidden in Mondeca ITM. Assertions types have
> to be declared, and the assertion type constrains the assertion pattern. As far as I
> understand, every other TM application does more or less the same. That's why I don't see
> the point of letting the door open to untyped assertions, except for sake of letting
> people keep on being loose and lazy.
>
> > > > I would like the rationale of Note 21 to be
> > > > expanded. On this father-child relationship, for example.
>
> It does not seem to me that your long answer addresses my question. I agree that if I want
> to speak about the set of my children, this set is a subject and has to be represented by
> a single node. But my question is why should I be forced into speaking about that set if
> I'm not interested in it? Why am I not allowed by RM to express in a single assertion.
> "Bernard is the father of Alice, of Claire and of Jan", without making any explicit
> assertion about the set {Alice, Claire, Jan}. Moreover, role type of each of my children
> in such an assertion ("child") is quite natural, but role type of the *set* seems
> difficult to conceive and name. I'm not the father of a set, but, certainly in different
> ways, the father of three distinct children, right? So in that case I suppose I have to
> utter three different assertions?
>
> So I see what the constraint 3.6.4.2.1 "No multiple role players of a single role type"
> enforces unto the representation in some cases, but I fail to see what problem(s) it
> solves. Particularly, I don't see how multiple players of the same role type can break
> Subject Location Uniqueness.
>
> Bernard
>
> -------------------------------------------------------------------
> Bernard Vatant
> Consultant - Mondeca
> www.mondeca.com
> Chair - OASIS TM PubSubj Technical Committee
> www.oasis-open.org/committees/tm-pubsubj/
> -------------------------------------------------------------------
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@acm.org
Web: http://www.topicmapping.com