[sc34wg3] HyTM as a SAM syntax

[Steve Pepper]

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?

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.

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

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

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

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

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.

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.

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

Steve

--
Steve Pepper, Ontopian
http://www.ontopia.net
DUMUS DELENDUM EST