[sc34wg3] HyTM as a SAM syntax

[Martin Bryan]

Steve Pepper wrote:


> At 17:09 16.04.2003 +0100, Martin Bryan wrote:
> >My use of HyTM was extremely deliberate. While SAM, XTM and HyTM
certainly
> >share the concepts you name, they also fail to share certain concepts.
For
> >example SubjectIndicators are not part of HyTM and facets are not part of
> >XTM or SAM. What I want to explore, as a matter of urgency, is the
problem
> >of trying to use TMAs that only partly overlap to allow systems to be
able
> >to combine information.
>
> This actually begs another question: Can the SAM accomodate all HyTM
> concepts or only some of them?

Well, I'm sure you can guess my answer to that ;-)

> Martin seems to be asking for HyTM to be used as the example of TMA#2
> and for a mapping to be provided to the RM. I appreciate where Martin is
> coming from, but I what he wants is doubly erroneous:
>
> Firstly - and for the same reason that a mapping from some "STM" DTD to
> the RM would be a waste of energy - HyTM is an *interchange syntax*, not
> a *data model*. A "Topic Map Application", as the RM conceives it,
> cannot be an interchange syntax; it must be a data model (otherwise we
> are back to square one, year 2000, a syntax and no implementable data
> model). So, Martin, if you want HyTM to figure in the mapping to the
> RM, you have to first define a TMA, a data model, i.e., an alternative
> to SAM. Then that alternative can be mapped to the RM.

But Steve, you obviously failed to notice Annex C to the HyTM spec, the HyTM
Grove Plan, which will provide a model for the information. OK, the model is
expressed as a syntax, but it should be possible to describe that model
using the reference model in a TMA.

> Secondly - defining such a TMA would be a waste of time unless it were
> first proven that the SAM cannot accomodate HyTM. Before asking to see
> a HyTM to RM mapping, I would like to be convinced that the SAM is not
> able to accomodate HyTM.

The question is not whether the SAM can be stretched to cover HyTM (as the
existing deserialization proposal clearly is) but whether or not a more
efficient representation can be provided as a TMA.

> The working hypothesis at the moment, based on the Roadmap, is that the
> SAM *should* be able to accomodate everything that is relevant to topic
> map processing that can be expressed in HyTM. The work on the HyTM
> deserialization syntax will show us if this is the case or not. If you
> believe, Martin, that you have already demonstrated that it cannot,
> please make this clear.

I have to both Lars and Graham, the approved authors of the SAM. The problem
is that their proposal that facets be turned into topics and associated with
occurrences or topics, and that scopes and added themes be flattened out at
the lowest applicable level, prohibit the effective roundtripping of a HyTM
document to and from SAM, and also makes it difficult to convert an XTM
document to HyTM and vice versa.

> (Unfortunately I still haven't been able to study the HyTM draft in
> detail, but I promise to do so soon. From a cursory glance, it does
> not seem to demonstrate that HyTM instances cannot be deserialized
> to the SAM, although there *are* unresolved issues.)
>
> Here is my view on the tricky aspects of this deserialization:
>
> 1. I believe that <facet>s *can* be handled in the SAM.

But can they be round-tripped or handled efficiently?

> 2. So can <topicmap 'addthems'>, <topic 'scope'> and <addthms>.

Not if, like me, you believe that scope is an any rather than an all
scenario.

> 3. I'm less sure about the mnemonics:
>
>     <topic 'linktype'>
>     <occurs 'occrl'>
>     <assoc 'linktype'>
>     <assocrl 'anchrol'>
>     <facet 'linktype'>
>     <fvalue 'facetval'>
>
>     but, on balance, I believe they *can* be handled. (I will be
>     curious to see what you did with them in the HyTM draft, Martin.)

By cobbling together rules for the creation of topics for the expression of
this information. Ugly, inefficient and horrible to look at it is the only
way I could find given Lars Marius' repeated dictum of "create a topic to
express everything that is not a topic".

> 4. <topic 'identity'> suffers from underspecification. It does not
>     allow us to make the distinction (necessary in the SAM) between
>     direct and indirect identification of subjects. My proposal for
>     solving this would be to say that the value of the 'identity'
>     attribute should always be regarded as a [subject identifier]
>     rather than a [subject address], but there are other alternatives.
>     That's a discussion we can have on the Friday afternoon in London.

I can live with this as, for the moment, identity maps to the SAM Locator
object that is referenced as a subject identifier.

> 5. There are also a bunch of things in HyTM that I believe are HyTime
>     machinery, pure-and-simple. They would be represented in a HyTime
>     grove, but not in a topic map 'grove' (or internal data structure).
>     This includes things like <assocrl 'multmem'>, which I believe
>     should be thrown away when deserializing HyTM as a topic map.

No question that much of the HyTime stuff, which is designed to be be fixed
in the DTD rather than used in the instance in all but exeptional cases, is
not needed in SAM, which is purely instance orientated.

> *If* it turns out that HyTM lets you do things with topic maps that
> the SAM can't accomodate, then we have to choose from the following
> options:
>
> (1) define a second Standard TMA (for HyTM) - (Son of SAM? :-)
> (2) adapt HyTM and/or the SAM so that they fit together, or
> (3) throw out HyTM altogether.
>
> However, before discussing those options, let's see whether SAM can
> handle HyTM or not.

But let's also realize that we shouldn't throw away potentially useful
existing techniques just because we need a simplified SAM. Option (3) on
your list would mean that some useful shortcuts, which allow Topic Maps to
be used as stereotypes within larger data models, would be thrown out in an
effort to force everything to a fixed XML view of the world. I'd prefer to
see SAM extended, possibly with some optional objects, to provide efficient
handling of all HyTM techniques, but then I'm almost as biased as your
supposed to be Steve :-))

Martin Bryan