[sc34wg3] RM4TM SLUO : Objective or Requirement?

[Steven R. Newcomb]

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

[Sam Hunting:]
> > ...in the same way we tried
> > to reserve association for the SAM, and assertion
> > for the RM, we tried to reserve topic for the SAM,
> > and node for the RM. Also, graphs have nodes
> > (unless they have vertices ;-)

> Well, why do we need different vocabulary for RM and
> SAM?  It figures they do not speak about the same
> subjects, and in that case what are the differences,
> and what is the mapping?

The mappings are for TM Applications, such as the SAM,
to make explicit, in accordance with the rules
specified in the RM.  The rules can be simple and
straightforward, or subtle and complex, or both.  Under
the draft RM, the SAM can be literally anything we want
it to be, except ambiguous.

For example, at this time, anyway, it seems that an
<association>, in XTM terms, cannot always be fully
represented as a single assertion in RM4TM terms.  And
there is no reason why we must bring <association>s and
assertions into complete alignment with each other.
It's true that we must specify, in the Syntax
Processing Model for XTM, how <association>s must be
interpreted in terms of nodes and assertions, but the
rules for making such interpretations can be just as
complex (or as simple) as we want them to be.

> > > notion of having nodes in the TMG representing
> > > "implicit" subjects that are not topics in the
> > > corresponding topic map is IMO extremely
> > > confusing and hard to grasp.

Maybe an example will help.  Here is an example from a
note I sent to Martin last April.  You can regard this
example as being based on a possible (but still
mythical) Syntax Processing Model for the HyTM syntax.

First, a brief excerpt from a mythical HyTM topic map.

<person 
 HyTM=topic 
 id=abeLincoln 
 identity=abeLincolnSI>
  <topname>
    <basename scope="foo">Abraham Lincoln</basename>
  </topname>
  <biography
   scope=bar
   type=unauthorizedBiography>
    <idloc>abeBio</idloc>
  </biography>
</person>

The above is a HyTM <topic> element (HyTM=topic) whose
generic identifier indicates its topic type (person).
Its subject indicator is the element whose unique
identifier is "abeLincolnSI".  It has a basename
"Abraham Lincoln" in the scope of "foo".  It has an
occurrence which is the element whose unique identifier
is "abeBio", in the scope of "bar".  (Please take my
word for all this; some of the HyTime incantations that
make all these things true are not shown above.)

The <person> element is really a <topic> element, and
it's the only *explicit* topic in this excerpt.
However, in the above fragment, there are no fewer than
24 subjects that, according to our mythical Syntax
Processing Model, must be represented by nodes in the
topic map graph, only one of which is explicit.  The
other 23 of them are "implicit" in the sense of that
word as used in the passage that you, Bernard, are
quoting from the RM4TM draft.

 #0. A specific human individual commonly known as
     "Abraham Lincoln".  This is the subject of the
     <topic> element (i.e., the <person> element, which
     is derived from the architectural form element
     type, <topic>)

 #1. The topic type of human individuals.

 #2. The name "person".

 #3. The assertion that #2 is a name of #1.

 #4. The addressable subject that is the subject
     indicator for the subject of the <topic> element.
     It is the piece of information referenced by the
     string, "abeLincolnSI".

 #5. The assertion that #3 is a subject indicator of
     #0.

 #6. The name "Abraham Lincoln".  (Note: this is *not*
     the string "Abraham Lincoln" as it appears in the
     above example; if it were, it would be an
     addressable subject.  Subject #6 is
     nonaddressable; it is the name "Abraham Lincoln"
     in the abstract sense; it is the name that is
     meant by *any* copy of that string, anywhere.  In
     this list of subjects, I'm not bothering to use
     the appearances of names in the example as subject
     indicators for those names.  There is no need to
     do that if they already have subject indicators
     located elsewhere, and I'm assuming that they do.)

 #7. The assertion that #6 is a name of #0.

 #8. The subject of the topic that is referenced by the
     string "foo".

 #9. The set of subjects that has #8 as its only
     member.

#10. The assertion that #8 is a member of #9.

#11. The assertion that #9 is the scope of #7.

#12. The occurrence type of unauthorized biography.
     (In dRM terms, this is an assertion type.)

#13. The name "biography".

#14. The assertion that #13 is a name of #12.

#15. The name "unauthorizedBiography".

#16. The assertion that #15 is a name of #12.

#17. The addressable subject that is the occurrence of
     an unauthorized biography.  It is the piece of
     information referenced by the string, "abeBio".

#18. The assertion that #17 is an unauthorized
     biography occurrence of $0.

#19. The subject of the topic that is referenced by the
     string "bar".

#20. The set of subjects that has #19 as its only
     member.

#21. The assertion that #19 is a member of #20.

#22. The assertion that #20 is the scope of #18.

#23. The assertion that #0 is an instance of #1.
     (Sorry, this one should have appeared earlier in
     this list.)

Question: Why do we need to make all these things
          explicit in the topic map graph?

Answer: So that:

        (1) anybody can say anything about anything in
            any topic map, including about subjects that
            are only implicit in other topic maps,

        (2) all topic maps can be merged,

        (3) the result can be a topic map graph that
            honors the Subject Location Uniqueness
            Objective, and

        (4) queries of the contents of topic maps will
            behave the same way after merging as they
            did before, except possibly for giving more
            results.

Note: Actually, in terms of RM4TM, there are even more
      subjects involved in the above example, if we
      count all the assertion types, role types, and
      c-nodes.

> ...A fully-merged topic map graph
> is then a "telos", and as such cannot be given any
> formal definition. OTOH, what can be formally defined
> is a topic map *fully merged according to some SIDP*,
> which means this SIDP achieves a one-to-one
> correspondance between nodes and p-values. That I am
> ready to buy.

Hooray!  I am very glad you are ready to buy this.
(Actually, it's not necessarily as simple as "a
one-to-one correspondence between nodes and p-values".
It's only that simple if the TM Application's
definition makes it that simple.  It is always true
that SIDP values determine subject identity, for all
purposes of achieving "fully merged"-ness, but the
rules for comparing SIDP values to determine whether
they identify the same subject are defined by TM
Applications, and these rules can be arbitrarily
complex.)

I have only one tiny, purely editorial complaint with
what you've said above: you're blurring the definition
of "fully merged" with "the full achievement of the
Subject Location Uniqueness Objective".  "Fully merged"
is supposed to be used only to describe the result of
the SIDP-based merging process -- nothing more than
that.  

(I really can't complain too much about the fact that
you're blurring this distinction.  We blurred the same
distinction in Informative Annex A, and we blurred it
very thoroughly indeed.  I think we should either edit
Annex A, or characterize this Annex as
"Misinformatively Oversimplified" instead of
"Informative".)

> > If you don't have the Subject Location Uniqueness
> > Objective, you don't have a topic map, any more
> > than the indexer would if she had two cards for the
> > same entry.

> Hmm. I would say you have a topic map, but a
> suboptimal one ...

Yes, so would I.  I'd say it could even be a
"well-formed topic map".  Just not a "fully merged"
one.

[Sam]
> > So, what do you mean, "only" an objective? The
> > objective is the raison d'etre of the entire
> > standard -- it needs a "shall" not a "should."

[Bernard]
> Hmm again. I'm not sure I would go that far, since
> this Objective is only a telos. What is the way to
> express a Telos?  Is "We shall overcome" an
> Objective, or a Requirement? :))

I agree with Sam's emotions, and with Bernard's
argument.  Editorially, we have to tiptoe around this
*very* precisely.

> What does the SLUO try to describe: the utopia of a
> process, or a conformant state of some stage in this
> process? If it is an utopia, it's good as is, but
> forget about any formal expression of it.  OTOH, a
> weaker form (achievement of SLU according to a given
> SIDP) can be formally expressed.

I think that's exactly right.  We tried to call that
weaker form "fully merged" consistently throughout the
draft RM, while we called the strong utopian objective
"the Subject Location Uniqueness Objective" (always
capitalized).  (But in Annex A, we mixed up the strong
and weak forms in the hope of having people understand
what we were trying to do, without forcing them to
understand the details and limitations.  In retrospect,
it seems to have been a bad idea.)

> You mean subject identity *is defined by SIDPs*,
> right? In that case, we are tuned.  It goes along the
> line that subject identity is only
> arbitrary/legal/sociological and not
> absolute/metaphysical/ontological.  It is defined
> through an interagreement process, of which SIDP is
> the visible mark.

Yes!

> > > Subjects that are considered implicitly distinct
> > > in a given topic map, on the basis that they are
> > > represented by distinct topics with distinct
> > > SIDPs, might be considered identical by another
> > > topic map on the basis of new discovered
> > > properties ...  This is a frequent process in
> > > progress of knowledge that subjects considered as
> > > distinct at some point are discovered as being
> > > the same later on. Think about various historical
> > > apparitions of Halley's comet before Halley's
> > > discovery that they were the same one returning
> > > ...
> >
> > > So the RM has to ensure that merging does not
> > > split existing subjects,
> >
> > No, applications have to do that.
> 
> OK

Well, I guess I agree with the statement that
"applications have to do that", as long as you're using
a lower-case "a" in "application" (so you're not
talking about a TM Application), and what you mean is
that people who are creating topic maps may choose to
incorporate other topic maps and then make distinctions
that those topic maps didn't make.

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