[sc34wg3] Draft Reference Model

[Martin Bryan]

Steve

While I see what you are getting at with the following example, I still
don't agree with the need to differentiate between role types.

> 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

What you are saying in this is that this assertion has two distinct role
types "Opposite of White" and "Opposite of Black". 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. 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. It should only concern itself with the
uniqueness of role type/player pairs in specific instances.

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

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

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

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.

Martin Bryan