[sc34wg3] The interpretation of mnemonics

[Martin Bryan]

I'll start with my responses to Steve Pepper's long but highly relevant
e-mails re facets and mnemonics by taking up the challenge at the end of his
e-mail on mnemonics:

> I think those are two things we would be better off without,
> but if Martin can present a convincing case for retaining
> mnemonics (I doubt anyone else will even try :-), I'm willing to
> do so based on the proposal above.

There are two major reasons for wanting to retain the mnemonics options
provided by HyTM, and two minor reasons. The major reasons are:
1) The ability to map locally significant simplifications of TMs, such as
NewsML, to topic map applications
2) The ability to process topic maps using element-aware languages such as
DSSSL and XSLT simply, without having to provide multiple rules for an
element that depend on its attribute values or its contents.

The minor reasons are:
i) That you can write DTDs that validate the conformance of a TM to a
template much more easily (GIs can be used in model control, but attribute
values cannot)
ii) That you do not need to confuse users by listing topics that are only
used as part of the topic map control mechnism.

[Aside: I am definitely not of, and am diametrically opposed to, Steve's
camp of "If you want to say something, say it with a topic". To me this is
just a way of muddying topic maps as far as end-users are concerned.]

I could extend both these lists, but I think as they stand they are
sufficient reason for the retention of the mnemonic functionality.

In what follows I'll cut out Steve's excellent overview of the situation,
and only leave those parts of Steve's message I disagree with.

> In fact, the mnemonics I have shown for <topic> and <fvalue> are
> not explicitly termed "mnemonics" in 13250, although all the
> others are. (This is the significance of column (a).) However, I
> believe all these attributes share the same general properties,
> serve the same purpose, and should be treated in the same way.

I concur with this conclusion, and have always considered the fvalue
facetval and type attributes as identical to the occrl and type attributes
of occurs elements.

[Aside: I'll come back to this relationship in my response on facets. Its
key to understanding facets.]

> 3. Mnemonics and the 'type' attribute
> -------------------------------------
>
> Another thing that most mnemonics have in common is that they
> convey essentially the same kind of information as the 'type'
> attribute on the corresponding element. This is stated
> explicitly in 13250 for every mnemonic except those on <topic>
> and <fvalue> elements. (This is the significance of column (c).)
> For <topic> elements, 13250 explicitly states (Note 24, page 11)
> that
>
>    Neither the value of the linktype attribute nor the generic
>    identifier of a topic link has any significance with respect
>    to the topic mapping semantics defined by this International
>    Standard.

The key word in Note 24 is the word "mapping". I have always taken it to
mean "merging". What this informative note is saying is that the fact that
element X is defined with GI ABC and element Y is defined using linktype ABC
this will not affect the merging of the topics if they share the same
basename in the same scope.

> In the case of the <fvalue> mnemonic the text is less clear but
> I believe the intention was that it too should convey the same
> kind of information as the 'type' attribute.

The fact that both occrl and facetval attributes have exactly the same
wording regarding their relationship with the GI name suggests strongly that
this is the case, even if the preceding sentences do not match, so that the
word mnemonic does not appear in facetval. (In fact, it is not so much a
mnemonic as the actual value in this case, so I think the dropping of the
word mnemonic is actually correct.)

> 4. Inconsistencies with mnemonics
> ---------------------------------
>
> Why are mnemonics treated differently for <topic> elements? I do
> not know. There may be a good reason but it is nowhere stated.

There is no difference. You've simply misinterpreted Note 24 as far as I can
tell. What is important, though, is the fact that for topics there is no
type attribute, but a types attribute, to allow topics to be polymorphic.
The linktype attribute, which serves the role of occrl, etc, is a standard
HyTime attribute that applies to any varlink derived element, which is what
a topic or an association is. We simply took this inherited attribute and
applied it as the type defining aspect of a topic element.

> It could conceivably have to do with the fact that <topic>
> elements do not have 'type' attributes - they have 'types'
> attributes (because topics, unlike all the other constructs, can
> belong to multiple classes) - but I doubt it.

This does not change the way in which mnemonics work for topics in any way.

> Most likely it is just another one of the inconsistencies and
> lacunae 13250 is riddled with. (Those inconsistencies, by the
> way, can mostly be traced back to the fact that 13250 was
> standardized without a formal data model and in the absence of
> sufficient implementation experience.) Perhaps it really was the
> intention, despite Note 24, that the 'linktype' attribute should
> convey the same kind of information as the 'types' attribute. In
> that case, Note 24 should be regarded as a bug and removed.

The 'linktype' attribute cannot convey *exactly* the same kind of
information as the 'types' attribute in this case. The linktype attribute
inherited from HyTime could not cope with polymorphism. So we had to invent
a polymorphic equivalent, the types attribute. When we came to reuse this
construct for associations and facets we realised that polymorphism was not
appropriate in these situations, so we ended up with a one-to-one map
between type/linktype/GI that we could not obtain using types/linktype/GI.
Do not be confused by the fact that in some cases there is a mapping and in
others there isn't. Its the types/linktype/GI mismatch that makes it
important to hold mnemonic information separately from the type information.

> If, on the other hand, Note 24 is to be taken at face value,
> then anyone designing client DTDs with element types derived
> from the <topic> architectural form (as in my <language>
> example, above) has been wasting their time creating topic maps
> whose semantics are not interchangeable.
>
> A bug in 13250, or broken topic maps? Clearly, this issue needs
> to be resolved, urgently.

Or your misintepretation of the 13250 wording needs to be resolved urgently
;-)

> So why are mnemonics treated differently for <fvalue> elements?
> Again, I don't know. There could have been a Note 50, like the
> notes on all the other mnemonic-bearing element types (except
> for <topic>) but there isn't. Probably just another minor
> inconsistency.

Yes. It's actually one that I've had noted in my copyof the standard for
many years. It's just that we've never discussed updates to the text as yet.

> 5. Mnemonics in the SAM
> -----------------------
>
> In the light of the preceding discussion, how should mnemonics
> (and generic identifiers) be handled when deserializing to the
> SAM?
>
> In the case of generic identifiers, I think the answer is easy.
>
> In order for a HyTM document to be interpreted correctly it must
> first undergo architectural processing in conformance with the
> HyTime standard. This results in a document that conforms to the
> base DTD specified in 13250. At this point, the generic
> identifiers have all been "normalized" and their tokens have
> ended up as the values of the mnemonic attributes. So in
> practice we can forget about the generic identifiers and just
> focus on the mnemonics.

Agreed

> Since mnemonics convey the same kind of information as 'type'
> attributes, they should be treated in a similar way.

While they provide similar information they were deliberately designed not
to be treated in the same way within ISO 13250. The argument made at the
time, which is still valid, is whether or not users should view types as
separate topics or as controlling facets. Two mechanisms were provided to
allow for these two world views. One allowed them to be topics, and the
other allowed them to be controlling facets (i.e. property name/value pairs
associated with a specific instance of the element concerned). You wish to
force your worldview on those of us with an alternative worldview. I
strongly object to this.

> My proposal
> is as follows:
>
> 1) When both mnemonic and 'type' attributes are present, the
> mnemonic's value should become an additional base name in the
> scope "http://psi.topicmaps.org/hytm/1.0/#mnemonic" on the topic
> referenced by the 'type' attribute.
>
> 2) When only the mnemonic attribute is present, its value should
> become the base name in the scope
> "http://psi.topicmaps.org/hytm/1.1/#mnemonic" of a *new* topic.
> That topic should be made the value of the [type] property of
> the information item that corresponds to the element in question.

Fundamentally this is what I have proposed in HyTM should happen whenever a
mnemonic is deserialized into a SAM representation. I do not believe it
needs to be preserved, however. If I go from HyTM -> SAM -> HyTime I believe
the mnemonic should be restored. with the fact that is was a GI being noted
and implemented where relevant (i.e. I want two scoping PSIs,
http://psi.topicmaps.org/hytm/1.1/#mnemonic-GI and
http://psi.topicmaps.org/hytm/1.1/#mnemonic-linktype). If, however, you go
from HyTM -> SAM -> XTM then I believe the example given below is a
reasonable way to go.

> As an example of case 2):
>
>    <occurs occrl="email">mailto:pepper@ontopia.net</occurs>
>
> would become
>
>    <topic id="xyz123">
>      <baseName>
>        <scope>
>          <subjectIndicatorRef
>            xlink:href="http://psi.topicmaps.org/hytm/1.1/#mnemonic"/>
>        </scope>
>        <baseNameString>email</baseNameString>
>      </baseName>
>    </topic>
>
>    <occurrence>
>      <instanceOf>
>        <topicRef xlink:href="#xyz123"/>
>      </instanceOf>
>      <resourceRef xlink:href="mailto:pepper@ontopia.net"/>
>    </occurrence>
>
> Case 1) would be the same, except that there would already be a
> topic with the ID "email" (due to the 'type' attribute) which
> would get an additional base name identical to the one shown
> above.
>
> I believe this handles the mnemonic problem very cleanly and
> entirely within the model of the current draft of the SAM. There
> may be one or two tiny details that still need to be sorted out
> (in addition to the lack of clarity regarding mnemonics on
> <topic> conformant elements), but in principle I believe this
> simple proposal is workable.
>
> An alternative would be to throw out mnemonics altogether in a
> revised and non-backward compatible HyTM 1.1. I imagine this
> suggestion will drive Martin into a frenzy, but I know there are
> others who would see this as the best solution, not just me and
> the aforementioned editor in Dallas.

Frenzy attack occurs here :: HyTM is based on Architectural Forms. I know
you hate the concept, but I remain convinced that AFs are the only way to
map UML stereotypes properly to DTDs.

> The argument, I think, is that mnemonics give us just two things
> over and above what the 'type' attribute provides:
>
> (1) the ability to create quick and dirty topic maps that don't
> use topics when they should,* and

Your opinion of "should". As I said the other day, I see no reason why
<Index>
   <Entry>
       <GlossaryDef>
          <GlossaryRef>glossary.htm#TopicMap</GlossaryRef>
       </GlossaryDef>
       <Title>Topic Maps
           <Subtitle>application of</Subtitle>
       </Title>
       <References>
         <ReferenceID>chapter[1]/section[3]/p[5-7]</ReferenceID>
         <ReferenceID>chapter[2]/section[7]/p[2]</ReferenceID>
         <ReferenceID>chapter[3]/section[5]/p[6-7]</ReferenceID>
         <ReferenceID>chapter[4]/section[4]/p[5]</ReferenceID>
       </References>
    </Entry>
....
</Index>

should be deemed a "dirty topic map" just because you insist on calling a
topic a topic rather than an entry a topic.

> (2) a whole lot more overhead that we could really do without,
> given the complexity of the model we already have.

The level of overhead claimed is simply ludicrous. One additional property
is not going to ruin the model, or make its implementation that much harder.
Personally I'd prefer two, so that I could determine whether or not the
property was defined as a GI or a linktype attribute as to me GI defaulting
is the key to effective management of topic map templates based in DTDs.

Martin Bryan