[sc34wg3] a new name for the Reference Model

Sam Hunting sc34wg3@isotopicmaps.org
Thu, 2 Jan 2003 23:13:04 -0500 (EST)


Without comenting on the substance of the mail --

Steve--

    Sheesh! Can we try to maintain some minimal thread discipline
here? For my money, everything after "Here's what I think" is interesting,
important -- and shouldn't go under a thread titled "a new name for the
reference model". It's a whole new set of issues and deserves a thread of
its own. Can you repost?


On 2 Jan 2003, Steven R. Newcomb wrote:

> Jim Mason asks:
> 
>     > Do the names we give to standards say anything
>     > about what conforms to them?
> 
>     If the answer is "Yes", then I can say what I'd
>     like to be said:
> 
>     (1) The RM governs the definitions of Topic Map(s?)
>         Models whose specifications claim conformance
>         to the ISO Topic Maps paradigm.  The RM imposes
>         requirements on all TM Model definitions that
>         claim conformance to it.
> 
>     (2) Topic Map(s?) Models, including but not limited
>         to the Standard Model, govern the topic map
>         documents and enabling software that claim
>         conformance to them.  When a Topic Map(s?)
>         Model inherits ("borrows", includes) another
>         Topic Map(s?) Model, the inherited Model *also*
>         governs the documents and software that claims
>         conformance to the inheriting Model.
> 
>     How to say or imply all that in the names is a good
>     question.  I think we're already much closer than
>     we've ever been.
> 
>     > What conforms to what is still labelled the RM?
> 
>     Definitions of TM Models.
> 
>     > What does conformance to [the RM] mean?
> 
>     For the definition of any given TM Model, it means
>     that the RM's shopping list of required
>     definitions, and aspects of each definition, is
>     fully satisfied.
> 
>     > Likewise for what's still called SAM? Where does
>     > conformance to one of those say about conformance
>     > to what's currently out there as ISO/IEC 13250?
> 
>     OK, here's what I think.
> 
>     13250 is about two syntaxes for interchanging topic
>     maps: XTM and HyTM.
> 
>     XTM and HyTM are both inside and outside the SAM,
>     and that's why both the SAM and the RM are needed
>     in order to fully and rigorously describe what's
>     happening in 13250.  (Before anybody gets angry,
>     hear me out.  I don't think this formulation
>     threatens anybody or anything.)
> 
>     XTM and HyTM are inside the SAM because both
>     syntaxes invoke SAM-defined semantics, including:
> 
>     * occurrences
>     * names
>     * instance of class
>     * subject indicator
>     * addressable subject
>     * set
>     * scope
>     * etc.
> 
>     The SAM can define merging rules for all of the
>     subjects that are yielded by the above semantics,
>     but it can't define merging rules for subjects that
>     may be yielded by user-defined association types,
>     since we can't know what their semantics will be.
> 
>     Now, since both XTM and HyTM allow users to define
>     their own association types, the question arises:
> 
>       What does it mean when a subject is specified by
>       means of an association, and how does anyone
>       other than ISO standards-makers define the
>       merging rules for the subjects that may be
>       conferred upon role players by associations?
> 
>     I bet some readers are saying, "What in the hell
>     is Newcomb blathering about here?  Since when are
>     subjects conferred upon role players by
>     associations?"  Well, to make a long story short,
>     everything boils down to relationships between
>     subjects, and some relationships confer subjects on
>     the topics that play certain roles.  
> 
>     For example, there is the kind of relationship that
>     exists between a topic and its subject indicator.
>     One of the roles in such a relationship is played
>     by a subject indicator, which is always a piece of
>     information.  The other role is played by a topic.
>     The nature of this kind of relationship is such
>     that the *existence* of the relationship causes the
>     subject that is the meaning of the piece of
>     information (that plays the subject indicator role
>     type) to be conferred upon the topic (that plays
>     the other role).  That's an example of how a
>     relationship actually specifies the subject of a
>     topic.
> 
>     Now, let's look at the XTM syntax.  XTM syntax is
>     designed to make some relationships extremely easy
>     and intuitive to specify.  In fact, the XTM syntax
>     doesn't even make them look like relationships.
>     For example, instances of the <subjectIdentity>
>     element type establish the same kind of
>     relationship I've been talking about, between
>     topics and their subject indicators.  And the
>     purpose of a <subjectIdentity> element is to confer
>     a subject upon the <topic> that contains it.  It
>     does this by specifying that there is a
>     relationship between the topic and a subject
>     indicator.
> 
>     If you're still with me, here, you're ready for the
>     punch line: XTM *also* allows topic map authors to
>     specify *arbitrary* kinds of relationships, by
>     means of <association>s.  This is where the RM
>     comes into 13250 (i.e., into HyTM and XTM).  13250
>     not only has *inherent* kinds of relationships (the
>     significance of each of which is described in the
>     SAM), but also it allows and encourages
>     *user-defined* relationship semantics.  In other
>     words, HyTM/XTM has always expected that the SAM's
>     relationship semantics would be extended by users
>     of HyTM/XTM.
> 
>     What if some of those user-defined relationship
>     types are supposed to confer subjects on some of
>     their role players?  How do we tell when such
>     subjects are the same, and therefore must be
>     merged?  Neither 13250 nor the current SAM faces up
>     to the possibility:
> 
>     * that a user could define an association type
>       whose instances determine the subjects of one or
>       more their role players, and
> 
>     * that more than one topic may thus have conferred
>       upon it the same subject, and
> 
>     * that therefore such topics need to be merged.
> 
> 
>     We should decide what we want to do about this.  I
>     think there are several choices, including:
> 
>     (1) We do nothing.  We don't say anything about it.
>         We pretend the issue doesn't exist, and we face
>         it at some later date.  (I think this is the
>         worst possible choice.  It weakens both the SAM
>         and our credibility.  It creates a situation in
>         which weeds will thrive.)
> 
>     (2) We say that user-defined assertion types in
>         XTM/HyTM *are not* allowed to have any
>         semantics such that the subjects of any of
>         their role players are specified by instances
>         of such user-defined assertion types.  
> 
>         If we choose this option, whenever a topic map
>         author wants topics to be merged, he must say
>         so explicitly and redundantly, either with a
>         <topicRef> or with two <subjectIndicatorRef>s
>         to the same subject indicator.  Michel likes
>         this idea.  It protects developers of XTM/HyTM
>         processors from ever having to support
>         user-extensible merging rules, and it may have
>         other advantages of which I am not yet aware.
>         I dislike it because I think it should be
>         enough to say, in domain-specific terms (i.e.,
>         via instances of user-defined association
>         types), that topic A has subject S1, and topic
>         B has subject S1, and expect that A will merge
>         with B simply because they both have the same
>         subject.  It shouldn't *also* be necessary
>         to say explicitly:
> 
>           (i) that topic A also has subject indicator
>               SI1, and topic B also has subject
>               indicator SI1, or
> 
>          (ii) that topic A has the same subject as
>               topic B.
> 
>         If the SAM imposes a requirement to supply such
>         redundant information in each topic map, we
>         will eventually have to answer the following
>         embarrassing question, emanating from possibly
>         irate users: "Why does XTM/HyTM allow
>         user-defined association types at all, since
>         they aren't allowed to mean anything in terms
>         of subject recognition?"
> 
>     (3) We say that user-defined assertion types in
>         XTM/HyTM *are* allowed to have semantics such
>         that the subjects of their role players are
>         specified by instances of such user-defined
>         assertion types.  We require that, when such
>         topic maps are interchanged, they must include
>         the information necessary to allow such
>         subjects to be merged automatically, in the
>         normal course of topic map processing, whenever
>         such subjects are identical.
> 
>         Personally, I strongly favor this third choice.
>         It doesn't require us to delay the
>         standardization of the SAM, even though we may
>         wish to add stuff to the SAM, at some future
>         date, that *standardizes the expression* of the
>         additional TM Modeling information necessary to
>         extend the merging rules of XTM/HyTM in support
>         of domain-specific subjects.  It leaves
>         XTM/HyTM's future indefinitely long and
>         indefinitely bright -- as long and bright as
>         the full breadth and depth of the TM paradigm
>         itself.  It won't force XTM users to learn how
>         to make TM Models; it only leaves open the
>         possibility that they can use such knowledge if
>         they want to, without first having to abandon
>         XTM.
> 
>     In any case, we really need to face this issue.  
> 
>     > Does [the RM] specify or interpret?
> 
>     It specifies.  If it only interprets, then its
>     constraints are optional, and we abandon the idea
>     that "Topic Maps" means reliable, predictable,
>     ontology-neutral knowledge aggregation.
> 
>     > And this leads me back to a discussion in
>     > Baltimore about whether we need a multipart
>     > standard or multiple standards. If we have a
>     > multipart standard, I think it's easier to
>     > justify the RM as the much-needed explanation of
>     > what the current 13250 means, whether it turns
>     > out to be standard-like or TR-like.
> 
>     I don't see the RM as fully answering the question,
>     "What does 13250 mean?"  It provides an essential
>     part the answer, but it cannot provide the whole
>     answer.  The same is true of the SAM.  I see the RM
>     and SAM together as fully answering the question,
>     "What does 13250 mean?".
> 
>     The RM and SAM are both deeply technical.  The
>     answer to the question, "What does 13250 mean?" is
>     not light reading.  If if we pack both the SAM and
>     the RM into 13250, along with HyTM and XTM, we'll
>     have a big, heavy standard that nobody will read.
>     (I hesitate to mention three examples of too-heavy
>     standards: HyTime, STEP, and XML Schemas.  All
>     three are marketing disasters, despite whatever
>     technical virtues they may or may not have.  The
>     primary problem with all of them is that they are
>     TOO BIG.)
> 
>     We need Topic Maps to be *perceived* as light,
>     easy, and intuitive.  The XTM DTD gives this
>     impression.  Great!  
> 
>     So, if we go the multipart route, I want to be
>     very, very certain that the default, leading ISO
>     publication on Topic Maps is very short and sweet,
>     has the XTM DTD in it, and damn little else.  It
>     should be a "README" for Topic Maps.  
> 
>     I think we will defeat ourselves if we direct
>     public attention toward "ISO 13250", and people
>     look at it only to find that it's 100 pages of
>     mostly unintelligible techno-gibberish.  Even if
>     the first part of it is short, sweet, and
>     easy to understand, 100 pages is a big turn-off.
>     (I'm reminded of the guy who asks for a drink of
>     water, and then receives his drink in the form of a
>     blast from a firehose.)
> 
>     > If it's going to be a separate standard, then we
>     > have to make it a standard and be clear about
>     > what conforms to it. (If it's an abstract model
>     > of data or data aggregation or something like
>     > that and all that really conforms to it is 13250
>     > itself, then it shouldn't be a separate standard
>     > or even a separate document but rather a part of
>     > a revised 13250.)
> 
>     Any TM Model can conform to the RM, not just the
>     SAM, and not just XTM or HyTM.  13250 is not the
>     only thing that will ever conform to the RM, or to
>     the SAM, even.
> 
>     13250 is a standard for a pair of syntaxes.  Both
>     of these syntaxes are suitable for interchanging
>     Topic Maps that conform to the SAM, which is a TM
>     Model set forth in a separate standard.  Both of
>     these syntaxes inherently provide for the
>     expression of semantics (user-defined <association>
>     types) that are outside the scope of the SAM.  When
>     such non-SAM relationship semantics are used, they
>     must be defined in conformance with the RM, which
>     is *another* separate standard.
> 
>     > Another way of asking the question about what
>     > sorts of documents the RM and SAM are is to ask
>     > who the audience is. Are we writing these things
>     > for code writers or end users? That is to say,
>     > are we specifying the actions of a TM engine and
>     > the interchange formats for TM data, or are we
>     > marketing TMs/trying to help people who want to
>     > create TMs? At the moment, those two audiences
>     > are sometimes almost the same (that is to say,
>     > ourselves), but what about 5 years down the road?
>     > We need the information in both the RM and the
>     > SAM, but we need to understand how we need it.
> 
>     Here's my take on audiences:
> 
>     13250: It's for everybody, but it's especially
>            appealing to XML/SGML people.  (More and
>            more, that's everybody in any
>            knowledge-intensive field.)
> 
>     SAM: Audience is knowledge managers and software
>            developers: techies.
> 
>     RM: It's for Knowledge managers and software
>            developers: techies who want to achieve
>            subject location uniqueness for subjects
>            that are specified by domain-specific
>            relationship types.
> 
> 
> 
> 

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------