[sc34wg3] Draft Reference Model

[Steven R. Newcomb]

[Sam Hunting:]

> > As to your example, in the RM there is only one
> > player of the "sibling role." That player, can
> > however, be a subject that represents the set in
> > which all the siblings are members.

"Bernard Vatant" <bernard.vatant@mondeca.com> writes:

> Yes, but if I want to express only the sibling-ness
> between my brother, sisters and me (five siblings
> together) I have a single role type, right?

A single role type, yes, but not a single assertion.  A
set of assertions is required, one for each member of
the group of siblings (see the below diagram of such an
assertion).  Without those distinct assertions, there's
no way to talk about the fact that your brother is one
of the siblings -- there's no node whose subject is
that fact.  If you (or anyone else) decides to make an
assertion about the fact that your brother is one of
the siblings -- perhaps in order to allege that your
brother was really a shipwrecked infant space alien,
like Superman, that your family generously and secretly
adopted -- the graph must be restructured, and all user
experience with the old graph structure will become
invalid.  I don't think we want that to happen -- ever.
Instead, we need the RM's graph construction rules,
which guarantee that, whenever two topic map graphs are
merged, each of the original topic map graphs is an
unchanged subgraph of the resulting merged graph.  That
way, anybody who knew either of the original graphs
will find the merged result at least as usable as the
originals were.  All users of either of the original
graphs will be able to use their existing knowledge to
navigate the enriched topic space represented by the
topic map graph that resulted from merging them.

> My natural (and implemented) way to express that so
> far is to create one node to represent each sibling,
> and link them through an association with a single
> role-type (sibling). In the assertion of
> sibling-ness, my interest is to be able to browse
> from one sibling to another one. I'm not interested
> in the group of siblings as subject, 

... (but others might be interested, and their topic
maps must be able to merge with yours) ...

> and if I were,
> according to the RM, I'm not allowed to express an
> assertion with a single AC arc. 

Exactly right.

> So I'm confused now. How do I express sibling-ness
> (or similarity, or any equivalence relationship)?

First of all, you have to bow to the discipline of the
Subject Location Uniqueness Objective.  It demands,
among other things, that *all* of the subjects that
participate in a topic map, including subjects which
may only be implicit in our interchangeable instances,
be represented as nodes in the topic map graph.  This
means that there must be a node whose subject is the
group.  In the topic map graph, you can't "hide under
the rug" the fact that you're talking about a group of
siblings.  The group is a subject, regardless of
whether you wish to say anything about it, and so are
the memberships in that group.

For each sibling, you must assert that sibling's
membership in the group of siblings.  For example:


            groupOfSiblings-sibling
                assertion type                
                    (T)
    groupOfSiblings  |           sibling
            role     |            role
            (R)      |            (R) 
             |       |             |
             |       |             |
 (x)--------(C)-----(A)-----------(C)-------(x)
group            the membership            your
of               of your brother           brother
siblings         in the group
                 of siblings

Now we're in a position where any aspect of the group,
including its members' memberships in the group,
already occupies a location (i.e., is represented by a
node) in the graph.  No matter what else we may learn
about the group, or its memberships, these facts can be
added to the graph *without changing the existing
graph*.  The RM doesn't allow information to be lost on
account of topic map merging.

By the way, the assertion type doesn't have to be as
specialized as the one illustrated above.  I suspect
that a simple "set-member" assertion would work equally
well for your purpose:

                  set-member
                assertion type                
                    (T)
            set      |           member
            role     |            role
            (R)      |            (R) 
             |       |             |
             |       |             |
 (x)--------(C)-----(A)-----------(C)-------(x)
 the             the membership             the
 set             of the member             member
                 in the set




*******************************************************

> BV
> >> ... assertion type is still optional ...

> > Well, we call an assertion with no t-node
> > "untyped." It would seem to be that applications
> > could make OPs from this fact, and get whatever
> > functionality they watned from that.

> Hmm. Let lazy people do what they want with that
> facility. I won't use for myself those untyped
> assertions, untyped meaning no template ... the
> slippery way to haystacks ...

I feel the same way, Bernard.  Life is too short to
spend it expressing things ambiguously.

I wouldn't dream of constructing an XML document
without a DTD, either.  But XML's power to replace SGML
came, at least in part, from its ability to be parsed
in the absence of a DTD.  Most people just don't want
to bother with careful thinking before doing; first,
they want to *do*, and they want to *think* only when
their *doing* gets them into trouble.  It's human
nature, and the supreme rationalism of SGML did not
prevail over human nature.

So, I think we have to allow untyped assertions.  The
draft RM4TM proposes to keep untyped assertions from
causing any serious trouble by forbidding them to
confer any SIDP values; they are only allowed to confer
OP values.  So, they can't affect the subjects of
nodes, and, therefore, they can't have any effect on
the merging process.  It's a workable compromise; we're
compromising design purity with the messiness of human
nature.  We're allowing people to say what they want to
say, whenever they're ready to say it.  Would-be topic
map authors are invited to discover, after they have
become comfortable with the paradigm, and they have
invested in their own topic map(s), that they are in
trouble because they can't affect the subjects of nodes
using untyped assertions.  And then the Topic Maps
Paradigm rescues them, allowing them to discover the
way forward, which is to *think* and then *define their
assertion types*, at the time when they are motivated
to do so.  They become even more invested in the Topic
Maps Paradigm, because it was strong enough to offer
a solution to their problems.

Some of us are in the business of making the
construction of topic maps as easy as possible for the
users of their products.  This is a hard problem,
because the main advantages of topic maps are for the
*users* of topic maps, and those advantages generally
accrue to the users in proportion to the thought and
effort that was required in order to create them.  The
key to success for such products will be to minimize
the effort of creation, and especially to minimize the
effort of *starting* a topic mapping project.  The
success of topic map authoring products will depend
significantly on the gentleness with which their users
are introduced to the paradigm.  I worry that, if users
can't do anything without first learning how to define
assertion types, topic maps authoring products will not
succeed quickly, except perhaps in specialized markets.

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