[sc34wg3] RM4TM SLUO : Objective or Requirement?
Bernard Vatant
sc34wg3@isotopicmaps.org
Tue, 26 Nov 2002 09:25:59 +0100
Steve, Sam and al.
So it seems we agree after all on that point, modulo some fine-tuned editorial work ...
good news indeed :))
Bernard
----- Message d'origine -----
De : "Steven R. Newcomb" <srn@coolheads.com>
À : <sc34wg3@isotopicmaps.org>
Envoyé : mardi 26 novembre 2002 00:46
Objet : Re: [sc34wg3] RM4TM SLUO : Objective or Requirement?
> "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
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>