[sc34wg3] Re: Montreal meeting recommendations

[Steven R. Newcomb]

[Lars Marius:]
> Also, one question to SRN & MB that I personally have
> is: what is the purpose of the core model? What are
> its goals? Why is it being written?  I know the PMTM4
> document says something about this, but it's not
> obvious that this text necessarily applies to the new
> situation.  Enlightenment on this issue would be
> very much welcome.

I believe that at least one of the purposes of the core
model should be to protect investments in the creation,
implementation, and exploitation of:

  * instances of topic map documents / databases,

  * business models based on instances of topic maps
    or on the Topic Maps paradigm,

  * software that implements the Topic Maps paradigm, and

  * brands that are based on Topic Maps, that claim
    conformance to Topic Maps, and/or that contain the
    words "Topic Maps".

How does having a distinct "core" model protect these
investments?  It does this by giving the owners and
maintainers of such instances, businesses, software,
and brands room to adapt to changing conditions 

* without having to abandon conformance to the
  standard,

* without being justifiably accused of improperly using
  the "Topic Maps" brand name in connection with their
  products and services, 

  and, perhaps most importantly,

* without having to abandon the possibility of
  amalgamating knowledge that emanates from different
  sources, just because they don't all happen to use
  some particular set of "standard" association types.

Put another way, the purpose of having a core model is
to allow the Topic Maps paradigm and International
Standard to have "Applications" that are distinct from
the essential ("core") constraints and features that
are necessarily common to all topic maps.  The
relationship between the core model and all of its
possible "Applications" is analogous to the
relationship between the XML Recommendation and all of
the possible "Applications" of XML.  XML itself
constrains its Applications in certain ways, but only
in ways that enable all particular Applications to
exist.  This is the reason why XML is called, in ISO
jargon, an "enabling" standard, whereas any particular
XML Schema or XML DTD is a "constraining" standard that
partially defines an XML "Application".

Topic Maps, like XML, should be regarded and nurtured
as an "enabling" standard.  It should form a basis for
(i.e., "enable") the development and exploitation of
"constraining" standards.  The constraining standards
that are built on the Topic Maps paradigm, which I'm
here calling "Topic Maps Applications", should be
definable as

(1) sets of association types expressed as the
    subjects of topics (these topics may optionally be
    association templates), and

(2) optionally and additionally, if scope is used, as
    conventions for the use of scope.

If, in the Standard, we fail to distinguish between the
core notions of Topic Maps, on the one hand, and "Topic
Maps Applications", on the other hand, we will have to
constrain all conforming systems and instances to use
and support a specific Set of Association Types, and a
specific Doctrine for the Expression of Scope.  Anybody
who doesn't need or want these features, or whose
requirements include a deviant interpretation of what
constitutes a topic name or a topic occurrence, won't
be able to claim conformance.  Having concluded that
their application cannot conform to the "Topic Maps"
standard or paradigm, there will be nothing left for
them to conform to, and the opportunity for their
information to be amalgamated with other information
will probably be lost, even though that information,
like theirs, *could have conformed at least to the core
model*, which in any case would have greatly
facilitated the merging of these assets.

If people find the Topic Maps standard too
constraining, they won't use it, and the whole idea of
Topic Maps, or perhaps just the brand-name, "Topic
Maps", will ultimately be forgotten.  This will be a
bad outcome for those who have invested in the brand
name, "Topic Maps".  The purpose of any International
Standard is to provide a certain kind of protection for
certain kinds of investments.  If, however, the Topic
Maps brand name turns out to imply "conformance to the
Application-defining annoying straitjacket known as ISO
13250", then it will be ironic, unfair, and unjust that
those whose pioneering development investments
originally proved the concepts may not derive any
market advantage from them, and may even be
disadvantaged (!) in the marketplace by their previous
association with the Topic Maps brand.  Ugh.  We can
avoid this bad outcome by defining the essential nature
of Topic Maps separately from the Applications of that
essential nature, and by requiring that all
Applications be themselves defined in terms of that
essential nature -- the core model.  If we keep the
core separate from its Applications, then any kind of
worldview can become the basis of an Application.  A
separate core model gives Topic Maps the "Borg" [Star
Trek] advantage: "Resistance is futile.  You will be
assimilated."

It is neither unusual nor surprising that the whole
idea of topic maps as names, occurrences, and other
kinds of associations ultimately led, in the context of
the XTM work, to the discovery of an even higher level
of abstraction.  The distilled essence of topic maps
turned out to be associations (i.e., assertions of
relationships).  Names and occurrences turned out to be
two specific kinds of assertable relationships.  Names
and occurrences are still hugely important,
significant, and basic, both conceptually and
commercially, to practically everybody who uses Topic
Maps.  But because of the discovery of the ultimate
essence of what topic maps are, we're now free to avoid
the classic standardization error of weakening our
ability to adapt to changing conditions by making a
straitjacket for ourselves out of these two seminal but
application-specific ideas.

Another benefit of having a distinct core model is that
we, as individuals contributing to this committee
effort, don't have to fall on our swords if we can't
agree about the precise semantics of topic-basename or
topic-occurrence.  In our own private work, we can
still conform to the basic standard, and we can still
derive all of the basic benefits of conformance, even
if, for one reason or another, we can't conform to what
the standard turns out to say about how a basename (or
an occurrence) must be treated.  We can define our own
naming semantics, for example.  (This means, among many
other things, that those who have complained about the
Topic Naming Constraint can do what they think best,
and still accurately claim conformance to the ISO
standard.  Personally, though, I certainly hope that
the <name> element type in XTM syntax will still be
constrained to be parsed as a topic-basename assertion,
and that the semantics of topic-basename assertions
will still invoke the Topic Naming Constraint.)

So, what needs to happen?  Among other things, and in
no particular order:

* We should finalize the definition of the core model.
  It is worth noting that certain association templates
  must appear in the core model, including
  template-role-RPR, class-instance, and
  superclass-subclass, because these are needed in
  order to allow all Topic Maps Applications, including
  The Standard Application, to be defined.

* We should establish a set of association templates
  that collectively constitute "The Standard
  Application" of Topic Maps -- the application that is
  implied by the features currently present in the XTM
  and HyTime-based syntaxes.  Needless to say, these
  include topic-occurrence and topic-basename.  In
  order to do this, we really should establish an
  *enabling* standard for the expression of sets of
  association templates that is more convenient and
  intuitive than using XTM <association> elements whose
  template is template-role-RPR (this is still the only
  way we can do it in the current syntaxes, and I
  certainly agree with those who complain that it's
  inconvenient, non-intuitive, and ugly).  Maybe we
  should make small additions to each of the syntaxes
  in order to gain this convenience.  As I see it, the
  addition of such convenience features is completely
  consistent with existing practices in both syntaxes.
  After all, the XTM syntax, for example, already
  provides the <occurrence> element type, for example.
  In terms of the proposed core model, the only reason
  for the existence of the <occurrence> element type is
  to avoid the non-intuitiveness, inconvenience and
  ugliness of using <association> elements whose
  template is topic-occurrence, in order to say exactly
  the same thing.

* We should seek to define and establish a constraining
  "Standard Doctrine for the Expression of Scope".
  Incidentally, we should investigate the
  possibility/practicality of establishing an
  *enabling* standard for the expression of
  *constraining* "Doctrines for the Expression of
  Scope", of which the "Standard Doctrine for the
  Expression of Scope" would then become a shining
  example.  Personally, I think WG3 has a lot of
  requirements gathering and design work to do here.
  (To me, this looks like the richest unplowed field --
  perhaps even richer than TMQL and TMCL.)

Let's return to the question, "What constitutes an
*Application* of the core model?"  Again, I believe the
answer is, fundamentally:

(1) some set of association types, each of which is
    optionally provided with constraints expressed in
    the form of an association template, and

(2) if scope is used, some doctrine for the expression
    of scope.

What is an "association type"?  First of all, it's the
subject of a topic.  We don't constrain the expression
of subjects, nor should we.  However, I think we really
must insist that, at least in the normative text of The
Standard Application, the expression of each
association type must comprehensively describe all of
the application semantics that are implied by any
instance of such an association.  For example, in the
case of the topic-basename association type, all of the
expectations surrounding topic namespaces and the Topic
Naming Constraint, among other things, must be fully
expounded.  (Yes, the Topic Naming Constraint is not
part of the core.  It's really something that is
inherent only in the topic-basename association type,
which should be part of The (optional) Standard
Application.)

Each Topic Maps Application may optionally also define
an interchange syntax.  If it does, there must also be
a Parsing Model for that syntax that rigorously
specifies how that syntax must be understood in terms
of the core model.  Obviously, the ISO standard needs a
Parsing Model for each of its standard syntaxes (both
the XTM and HyTime-based syntaxes).

(Interestingly, some specialized Topic Maps
Applications may use syntaxes designed to facilitate
the expression not only of some set of association
types, as the XTM and HyTime-based syntaxes do, but
also for expressing constellations of scoping topics in
keeping with some particular Doctrine for the
Expression of Scope.  We don't have to worry about such
niceties in the International Standard, but it seems
likely that verticals will find interesting
opportunities in this area, as will TopicMaps.Org.)

Each application may optionally also define an API,
and/or a Property Set, and/or a UML model, etc.  I
think it would be great if we could provide The
Standard Application with ALL of these things.

To return to the original question, "What is the
purpose of the core model?"  Here's another way of
putting my answer:

  The purpose of the core model is an essential aspect
  of the task of extending to the general public the
  franchise of creating constraining Topic Maps
  Applications.

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA