[sc34wg3] Draft Reference Model
Steven R. Newcomb
sc34wg3@isotopicmaps.org
23 Nov 2002 15:37:17 -0600
"Martin Bryan" <mtbryan@sgml.u-net.com> writes:
> What you are saying in this is that this assertion
> has two distinct role types "Opposite of White" and
> "Opposite of Black".
No, that's not what I'm saying. If I were saying that,
I'd be confusing the role players with the role types
(I'd be confusing the assertion instance with the
assertion type.)
> Similarly my brother and I are linked by two
> different role types "Brother of Ian" and "Brother of
> Martin". It is the pair of the role type and the
> role player that needs to be unique, not the role
> type itself.
You have a clever idea there, but I don't think
it will take us all the way home.
If I wanted to say (nonsensically, in this case, but
nevertheless) that Martin is his own brother, or that
white is the opposite of white, I wouldn't be able to
do it, using the solution you propose, because then,
after merging, I'd have only one role player playing a
single role, and I would therefore not be expressing a
relationship -- not even a relationship between a
subject and itself. That's just one reason why it's
vital to distinguish the semantics of the relationship
(the assertion type and its role types) from the
semantics of the role players.
The primary (and, to my own mind, at least,
overwhelmingly compelling) reason why RM4TM requires
all of the role players of an assertion to play
*distinct* roles is that the Subject Location
Uniqueness Objective cannot be achieved if we allow
multiple role players to play the same role. It's the
same issue as the "role players that are sets"
discussion that Bernard, I, and others have been
having. We can't allow a subject to exist in the graph
that doesn't have exactly one corresponding node.
To use your example:
brother-brother
(T)
|
brother | brother
(R) | (R)
| | |
| | |
(x)-----(C)-----(A)-----(C)-----(x)
Martin Martin and Ian
Ian are brothers
The above assertion cannot appear in a fully-merged
graph, because the two role types are the same subject.
Therefore, they must merge. Here's my attempt to
show the result of that merger:
brother
(R)
|
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
| brother-brother |
| (T) |
| | |
| | |
| | |
(x)-----(C)------(A)------(C)-----(x)
Martin Martin and Ian
Ian are brothers
The result is that, in effect, we have a set of role
players {Martin, Ian} that play the same role
("brother"), but no node that represents that set.
At this point, somebody is bound to say, "Why, yes
there is a node that represents the group: the a-node's
subject is that Martin and Ian are brothers, so the
a-node's subject is the group!" But that's not true.
The subject that is the set {Martin, Ian} is not the
same subject that is the relationship of brotherhood
between Martin and Ian.
If we allow the above single-role assertion to occur in
a topic map graph, then similar situations can happen
multiple times in the topic map graph. For example,
there could be another assertion:
opposite
(R)
|
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
|opposite-opposite|
| (T) |
| | |
| | |
| | |
(x)-----(C)------(A)------(C)-----(x)
Martin Martin and Ian
Ian are opposites
Now we're really in the soup. We've said two
things about Martin and Ian:
(1) that Martin and Ian are brothers, and
(2) that Martin and Ian are opposites,
but there's no single location in the graph from the
perspective of which we can learn both of these facts
about {Martin, Ian}. That's a bad thing. RM4TM
disallows multiple role players of a single role
precisely in order to preserve subject location
uniqueness.
Using the RM4TM idiom, a good way to accomplish your
purpose is by the following assertions:
Assertion #1:
set-member
(T)
|
set | member
(R) | (R)
| | |
| | |
| | |
(x)-------(C)--------(A)--------(C)-------(x)
{Martin, Ian} Martin is a Martin
member of the
set {Martin, Ian}
Assertion #2:
set-member
(T)
|
set | member
(R) | (R)
| | |
| | |
| | |
(x)-------(C)--------(A)--------(C)-------(x)
{Martin, Ian} Ian is a Ian
member of the
set {Martin, Ian}
Assertion #3:
class-instance
(T)
|
instance | class
(R) | (R)
| | |
| | |
| | |
(x)-------(C)--------(A)--------(C)-------(x)
{Martin, Ian} {Martin, Ian} sets whose
is a set whose members are
members are brothers brothers of
of each other each other
Assertion #4:
class-instance
(T)
|
instance | class
(R) | (R)
| | |
| | |
| | |
(x)-------(C)--------(A)--------(C)-------(x)
{Martin, Ian} {Martin, Ian} sets of two
is a set whose members whose
two members are members are
opposites of each opposites of
other each other
In a fully merged topic map graph that contains the
above assertions, the left-hand role player in each of
the above assertions is exactly the same node. From
the perspective of that node, whose subject is the set
{Martin, Ian}, we know everything about them.
Now let's imagine that, instead of Assertion #4, above,
we said:
Assertion #5:
opposite.1-opposite.2
(T)
|
opposite.1 | opposite.2
(R) | (R)
| | |
| | |
| | |
(x)-------(C)--------(A)--------(C)-------(x)
Martin Martin and Ian
Ian are
opposites
The Subject Location Uniqueness Objective is still
served, because every subject can still have a single
location.
But what happens if we use BOTH Assertion #4 and
Assertion #5?
Well, depending on how we've defined our TM
Application, we may or may not have said exactly the
same thing in two different ways. If we said exactly
the same thing, then the property values of the nodes
for Martin, Ian, and {Martin, Ian} would turn out to be
the same, regardless of whether the graph contained
Assertion #4, Assertion #5, or *both* Assertion #4
*and* Assertion #5.
It's a bit subtle, but it's important to understand
that, while the assertion structure determines the
values of the properties of nodes, it is quite possible
for the values of the properties of nodes to be the
same even when the graph structures are different.
(We've seen this phenomenon before, when we've thought
about making rules for serializing topic map graphs as
XTM. There are lots of equivalent ways to say the same
things.) It all depends on the definition of the
governing TM Application. The governing TM Application
defines (1) the down-translation from syntax to
assertions, and also (2) the down-translation from
assertions to property values. (Constructing
assertions from property values is an up-translation,
as is re-serializing an XTM instance from a topic map
graph; both of these transformations can be done
automatically by rules, but the rules themselves are
necessarily arbitrary, and the information won't
necessarily *look* the same after making the
round-trip, even if it *means* the same thing at the
graph level.)
> My conclusion is that the role type is not a
> distinguishing property. It is simply a property that
> allows you to identify sets of assertions that play a
> similar role in different assertion instances. The RM
> should not concern itself about the fact that the
> same role type occurs in different places.
I disagree. This statement, that the RM should not
concern itself about the fact that the same role type
occurs in different places, is contrary to the Subject
Location Uniqueness Objective, the purpose of which is
to make *everything* that is known about *every*
subject available from the *unique* perspective of that
subject. You seem to be suggesting that subjects that
are role types should be excused from the Subject
Location Uniqueness Objective. I can't see any reason
to excuse *any* subject from the Subject Location
Uniqueness Objective. If anything, it seems especially
unthinkable to excuse ontological subjects, such as
role types, from it.
> [The RM] should
> only concern itself with the uniqueness of role
> type/player pairs in specific instances.
I don't see how that would allow the SLUO to be
achieved, but I'm willing to learn.
> > 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
>
> This, I feel, is the role that is in error in the current RM.
I don't see it as an error. I see it as a success,
because it's such a simple way to guarantee the
sanctity of subject location uniqueness in the topic
map graph.
> > (2) that there can be only one role player per role type,
>
> This is the role that is actually needed.
>
> > ...the Subject Location Uniqueness Objective can't be
> > supported.
> I cannot agree with this statement. SLUO can be
> supported more simply by requiring the pair to be
> unique.
I'm interested in supporting SLUO in the simplest way
possible, so you definitely have my attention. But
I do not see how...
The role of brother is played by Martin, and
The role of brother is played by Ian
...can be interpreted in any way other than that
both Martin and Ian are playing the same role, which
makes Martin and Ian a set or group that is a subject,
but is a subject with no corresponding node.
> > 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.
> Nodes will have more than one "subject": they will
> have multiple assertions made about them. For
> example, I can think of cases where I am the
> guarantor of my my own validity (who reported Martin
> Bryan as being sick last week, Martin Bryan!), which
> may need to be expressed in some topic map
> someday. So then I'll have to distinguish the logical
> me from the physical one to make the nodes
> unique. (Assertion = [was-sick: Martin Bryan]
> [reported-by: Martin Bryan])
I'm baffled by this. Are you, or are you not, saying
that there is a subject whose name is Martin Bryan,
that is invariant regardless of who said what about it?
> All you are really saying, as far as I can tell, is
> that in any assertion a particular node can only play
> one role in the assertion. I'm not sure that this is
> really valid but what seems to me to be certain is
> that the pair of role and player must be unique for a
> given assertion.
I think I understand you, and it's a clever idea, but I
don't think it works, because it allows multiple role
players to play the same role, which implies a subject
which is a group, but for that subject there is no
node, so there's no way to aggregate knowledge about
that group around that group, so the SLUO cannot be
achieved.
-- 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