[sc34wg3] to advance Topic Maps

[Steven R. Newcomb]

In 1993, when we began to work on the problem of merging
independently-created indexes, and when we first coined the term
"Topic Maps", the objective was to know how and when to merge two
independently-created index entries, on account of the fact that we
(somehow) deemed them to have the same subject.  This facilitation of
this objective -- in its full generality -- has always been, and, at
least for me, continues to be the purpose of the Topic Maps standard.
The objective has never been to impose a single, one-size-fits-all
world-view on all users of ISO-standard Topic Maps.  In the early
days, we didn't realize how deeply our world-view had been embedded in
Topic Maps.  Now, we know better, and we see much more clearly what
we're doing, here.  We should see the SAM as an instance of a class of
TM Applications, and we should welcome the idea that each member of
that class can represent a different, potentially valid (and
necessarily limited) world-view.  When we promote the SAM, we should
be convinced that, among all existing and future TM Applications, the
SAM represents an outstanding balance of trade-offs -- a balance
worthy of publication by ISO for general use by the public.  We should
be able to articulate those trade-offs, and to defend the design of
the SAM in terms of those trade-offs.

We're not there yet, but, in the recently submitted Topic Maps Model
(TMM, SC34/N0393), we now have a tool for expressing and evaluating TM
Applications, and for discussing and making explicit the design
trade-offs they represent.  We have the opportunity to use this tool
to make the SAM a stellar example of a TM Application, and I hope we
will use it.

In order to advance Topic Maps, it is urgent that we align the SAM
with the requirements for TM Applications prescribed in the TMM.  In
order to do that:

(1) The SAM should be expressed and constrained in such a way that it
    is clear that the SAM can be extended, and that its extensions can
    extend the rules for merging and number of relationship types that
    can determine the subjects of their role players.

    Currently, the SAM makes no provision for such extensions.  The
    SAM provides no general doctrine for merging, in terms of which it
    explains both its own merging rules, and those that may be added
    by TM Applications that include (inherit) and extend the SAM.

    Specifically, the SAM does not say how (or even whether) the
    instances of user-defined association types can determine or
    influence whether their role players should merge.

(2) The SAM should be expressed and constrained in such a way that it
    is clear that topic maps that are based on the SAM can be merged
    rigorously and predictably, not only with each other, but also
    with topic maps that are not based on the SAM.

    The current SAM makes no provision for this.  

    The TMM shows how the SAM can be expressed in such a way as to
    allow other TM Applications, including but not limited to TM
    Applications that inherit (or "include") the SAM, to be
    independently designed and maintained without sacrificing the
    integrity of the topic maps that are based on them when SAM and
    non-SAM topic maps are merged.  

    It's important to maintain the integrity of knowledge even after
    it is merged with other knowledge.  The TMM is designed to meet
    the requirement of preserving the integrity of merged topic maps.

    Any data models that we publish for Topic Maps should be informed
    by sensible doctrines that establish the general rubric under
    which diverse merging rules must co-operate, despite the diversity
    of the knowledge domains and world-views from which they emanate.
    The TMM proposes such a rubric.

(3) The SAM should be expressed and constrained in such a way that it
    is clear that the SAM reflects the WG3's intentions regarding
    which subjects it reifies (which subjects are capable of being
    role players and are subject to merging), vs. which subjects are
    not reifiable in systems that are governed only by the SAM.

    The current SAM document does not clarify this.  In the absence of
    such clarification, there is no basis for any claims we (or
    anybody else) might make about the integrity with which knowledge
    is handled, even under the SAM's own rules.  The TMM requires all
    TM Applications to make explicit the limits of their support for
    the SLUO, and that their behaviors be deterministic and
    predictable, even in multi-source, multi-TM-Application
    environments.  (The "Subject Location Uniqueness Objective (SLUO)"
    is the principle that all topics that have the same subject should
    be merged.)  The support of every TM Application for the SLUO is
    necessarily limited.  It's important that users are able to know
    exactly how the SLUO is met by any TM Application(s) they use.

    The SAM, as currently written, doesn't state the limits of its
    support for the SLUO.  At least one of the things that the SAM
    does needs an especially detailed disclosure: the SAM allows the
    reification of subjects to be controlled, not by the inherent
    logic of the SAM, but rather by syntactic constructs that are used
    in a given interchangeable instance.  This makes the merging
    responsibilities of implementations ambiguous.  It becomes
    impossible, in the general case, to preserve the integrity of
    topic maps across merging operations with other topic maps,
    because if a subject is reified in one topic map, and unreified in
    another, the two topic maps cannot be merged into a single topic
    map that preserves the integrity of both originals.  If we decide
    that the SAM really should be designed in such a way that its
    implementations are exempted from respecting the SLUO in this way,
    then we must disclose the fact, and we must say exactly how all
    SAM implementations will uniformly resolve all the ensuing
    ambiguities.  Again, the TMM doesn't care how much or how little a
    TM Application respects the SLUO; it merely demands that the
    limits be disclosed.

In N0393, there's a checklist of things that need to be done when
defining a TM Application such as the SAM:
http://www.isotopicmaps.org/tmmm/TMMM-latest.html#parid0781.  There's
also a checklist for Syntax Deserialization Definitions, such as for
XTM and HyTM:
http://www.isotopicmaps.org/tmmm/TMMM-latest.html#parid0775.

It's possible to reconcile the SAM and the TMM.  I hope we will all
read the new SAM document (which is looking cleaner than ever -
http://www.isotopicmaps.org/sam/sam-model/), and the new TMM document,
too, with that goal.

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