[sc34wg3] Draft Reference Model
Steven R. Newcomb
sc34wg3@isotopicmaps.org
19 Nov 2002 21:07:26 -0600
"Bernard Vatant" <bernard.vatant@mondeca.com> writes:
> > [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)
Not in the draft Reference Model.
> > 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.
My previous note discusses how to express groups.
By "equivalence relationship" I'm going to assume that
you mean "relationships in which there's no semantic
difference between the role types". Such as opposites.
Let's suppose that we need to define a two-ended
relationship type in which each of the two role players
is the opposite of the other. There is no semantic
difference between the two role types, and yet there
must be a distinction between them, for purposes of the
RM, because otherwise they would merge into a single
topic, and then there would be multiple role players of
the same role type, which is illegal in the RM. And yet
there *can't* be a distinction between them, because
they are the same semantic. Right?
They way this is handled in the Reference Model is this:
You define two role types. Let's call them
"opposite.1" and "opposite.2". The distinction between
them is real: one of them is one of the two role types
of the "opposite.1-opposite.2" assertion type, and the
other is the other. But if they're not the same, how
can they mean the same thing? The answer is simple:
they can mean the same thing because each of them
confers property values on its role player that is
exactly like the property values that the other
confers. For example:
opposite.1-opposite.2
(T)
|
opposite.1 | opposite.2
(R) | (R)
| | |
| | |
(x)-----(C)-----(A)-----(C)-----(x)
black black and white
white are
opposites
The definition of the opposite.1-opposite.2 assertion
type says:
(1) The node that is the roleplayer of the "opposite.1"
role type is the value conferred upon the
myTMApplication::oppositeOf property of the node
that is the roleplayer of the "opposite.2" role
type.
(2) (The exact reverse:) The node that is the
roleplayer of the "opposite.2" role type is the
value conferred upon the
myTMApplication::oppositeOf property of the node
that is the roleplayer of the "opposite.1" role
type.
So, the two role types have the same effect, even
though the two role types are, for subject merging
purposes, different subjects.
Why, though, is it necessary to define two different
role types, even though one would do the job?
The answer is that without the rules:
(1) that all role types must be different, and
(2) that there can be only one role player per role type,
...the Subject Location Uniqueness Objective can't be
supported. This is the only way to guarantee that all
subjects have nodes, that no node has more than one
subject, and that merged graphs remain unchanged
subgraphs of the graphs that result from merging.
And it doesn't hurt anything. You may complain that
opposite.1 and opposite.2 aren't really different, but
that's not really true. Opposite.1 requires a property
value to be conferred on the basis of the roleplayer of
Opposite.2, whereas Opposite.2 does *not* define a
property value to be conferred on the basis of the
roleplayer of Opposite.2 Instead, it defines a property
value on the basis of the roleplayer of Opposite.1.
So, they are different, but symmetrical. Most
assertion types are assymetrical: different property
values are conferred on the different roleplayers, and
some roleplayers may not have any property values
conferred on them, while other roleplayers do.
Symmetrical assertion types are merely a special case,
where the affected properties happen to have the same
name, and a similar property value calculation is done
for each of the two roleplayers.
> > (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 ...
In the draft RM, the subject of a node is represented
by the values of its Subject Identity Discrimating
Properties (SIDPs). Typically these values are conferred
on the basis of the node's situation in the graph.
The situation of a node has some set of "situation features"
which cause values to be conferred on its properties.
Playing a particular role in an instance of a particular
assertion type can be defined as a "situation feature"
that causes values to be conferred on the properties of
the role player.
The draft RM says that assertion type definitions must
state, for the player of each role in all instances of the
assertion type, the values that must be conferred on the
properties of the role player.
"Instances" of untyped assertions are allowed to confer
values on the Other Properties of the nodes that play
their roles. The definitions of "floating" role types
(role types that are not parts of defined assertion
types) can specify that such values must be conferred.
However, in the draft RM4TM, untyped assertions are not
allowed to confer values on SIDPs. In other words,
they are not allowed to determine (or influence) the
subjects of their role players.
> > 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 ...
Maybe this is clearer now?
> > 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.
It's a question of compromising with human nature. I
talked about this in my last note. Otherwise, I
completely agree with your position.
> > > > 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?
I hope this is clearer now, after my last note. The
reasons are:
(1) Subject Location Uniqueness Objective
(2) Making sure that merged topic maps don't lose their
integrity in the merging process.
> 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.
Is this still a problem?
-- 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