[sc34wg3] Draft Reference Model

Martin Bryan sc34wg3@isotopicmaps.org
Mon, 25 Nov 2002 09:53:34 -0000


Steve

You're beginning to convince me that SLUO is a bad idea.

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

No one in their right mind could ever make such an illogical assertion. You
can never be the opposite of yourself or the brother of yourself, simply
because of the definition of the terms opposite and brother. Trying to base
a theory on the impossibility of doing the impossible is not a good idea.

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

Of this I am definitely not convinced. Are you saying that there is only one
author of ISO 13250. Are you going to remove your name, or Michel his? What
you are requiring is that every assertion only says part of the story. It
can only identify "the set of authors of ISO 13250". Note this is not "a set
of authors" but "the set of authors for instance X".

> To use your example:
>
>               brother-brother
>                     (T)
>                      |
>           brother    |    brother
>             (R)      |      (R)
>              |       |       |
>              |       |       |
>     (x)-----(C)-----(A)-----(C)-----(x)
>    Martin        Martin and         Ian
>                  Ian are brothers

Having to create an assertion whose name is "Martin and Ian are brothers" is
just illogical, and cannot be sustained in terms of what ISO 13250 allows to
be stated in topic maps. There would never be such an association in a topic
map. The topic map would presumably have an association of type "Are
related" that links the member Martin in the role of Brother and the member
Ian in the role of Brother. From the point of view of the user of the topic
map the important thing is that the relation of Ian to Martin is the same as
the relation of Martin to Ian. Anything that results in the loss of this
sameness is a loss to the logic of the topic map. The association would have
some ID, but nowhere would there be any need to state that the subject of
the association is anything to do with the role players. Now some topic map
engine could note that the two roles are the same, could create a set of
{Brother1, Brother2} to allow the two roles to be distinguished in the RM,
but how on earth would it create an assertion identifier that stated that
Martin and Ian are the specific players who are related by this assertion?

>I'll skip the illogical intermediate states you proposed, especially

> (2) that Martin and Ian are opposites,

(most brothers are opposites: I would want all facts that show the
associations between us to be linked to the same set, but to try to treat
Martin and Ian as some example of a pair of opposites is irrational to me)

and go to your "solution" of creating sets.

> 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

This just does not work for me. If I have a family with four brothers, then
I have to make 6 pairings for my sets according to your rules. Why force 6
assertions where one with mulitple matching roles will do?

You later say:

> You seem to be suggesting that subjects that
> are role types should be excused from the Subject
> Location Uniqueness Objective.

No I am not saying that. What I am saying here, as above, is that from the
user's perspective the two roles are exactly the same, and there is nothing
to distinguish the roles. Only when you apply the roles to role players do
you create something 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.

No way are Martin and Ian playing the same role. Ian is the "Brother of
Martin" (is-related:brother-of:Martin) and Martin is the "Brother of Ian"
(is-related:brother-of:Ian).  Incidentally I note that the triple
(Assertion-type:role-type:role-player) should always be a unique statement
of the place a role player has in an assertion.

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

There is one node Martin Bryan who took two roles in the assertion:
(reported-sick:was-sick:MartinBryan)
(reported-sick:reported-by:MartinBryan)

One is as the physical body suffering a sickness, the other is a "reporter
of facts". But no way am I going to create two subjects of Martin Bryan just
to conform to the SLUO rules. At some future date an employer may want to be
able to find out what percentage of staff reported themselves sick. They
cannot do this if you insist that both role players be different nodes.

This is not a unique situation, just one example of a reason why your rules
are counter-intuitive even if they make processing easier for the topic map
engine. We need to bear in mind that it is people who define associations,
and they will insist on doing it in the way that best conforms to their
world view. If we start imposing restrictions on what they can do simply to
simplify the processing rules then we will drive them away from our
solution. (Learn from the mistakes of RDF, please!)

Martin