[sc34wg3] Draft Reference Model

[Steven R. Newcomb]

"Martin Bryan" <mtbryan@sgml.u-net.com> writes:

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

I think you'll be surprised to know that I fervently
agree with your intent.  You're arguing against a
position that I do not hold!  Rather than answer each
point in your letter, which I think would only prolong
our miscommunication, let me just say that I think I
must have failed to communicate a vital piece of
information.  Please accept my apology for this
omission.  (Oops!)

The topic map graph model is definitely *not* for
users.  It's only for topic map engines.  It's the
representation of topic map information in which
everything has become fully explicit, so that machines
can take over because all good human sense has already
been applied, and all human-friendliness has already
been removed.  

The topic map graph, with its assertions and nodes, can
be regarded as a kind of assembly language for a
standard "topic map virtual machine" that provides
certain standard services in support of merging
operations.  HyTM and XTM can be regarded as analogous
to high-level programming languages, suitable for use
by human beings.  Few programmers ever even glance at
the assembly language output of their compilers, and I
predict that few topic map authors will ever look at
topic map graphs.  (And I agree with you that rubbing
the users' noses in graphs is a serious marketing error
that has greatly inhibited the adoption of RDF.  I hope
that eventually you will agree with me that the draft
RM4TM provides a platform for the creation of
Applications that give users the services and creative
opportunities they need *without* rubbing their noses
in graphs, while still preserving the universal merging
magic of topic maps.)

The draft RM4TM *does not* define any specific
relationship or alignment between HyTM <assoc>s (or XTM
<association>s) and RM4TM assertions.  True, there
*may* be a one-to-one correspondence between
<association>s and assertions, but there also may *not*
be such a correspondence.  Under the draft RM4TM, that
depends entirely on how the SAM is defined, and the SAM
isn't fully defined yet.  It especially depends on how
the Syntax Processing Models (or I should say,
"Deserialization Models") for XTM and HyTM are defined,
as part of the overall definition of the SAM.

So, the SAM can be defined in such a way as to permit
one-armed <association>s of the kind you favor and that
users can be comfortable with, and, even so, it can
*still* be 100% conformant to the RM.

I do, nevertheless, maintain firmly that one-armed
<association>s cannot be interpreted as one-armed
assertions, because there is no such animal as a
one-armed assertion, nor can there be, if we want to
honor the SLUO.  But one-armed <association>s can
certainly be interpreted as constellations of
multi-armed assertions -- there's just no doubt about
it.  All we have to do is to say exactly how, in the
deserialization model.

So, really, the question is not whether to allow
one-armed assertions.  The question is how to express
what we really mean, in terms of multi-armed
assertions, when we write one-armed <association>s.

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