[sc34wg3] HyTM as a SAM syntax

[Lars Marius Garshol]

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

I wondered about that. If you are going to specify a grove plan for
HyTM, why not do

  HyTM -> HyTM grove -> SAM

rather than

  HyTM -> HyTM grove
  HyTM -> SAM

which means doing all the donkey work twice?
 
| 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.

Well. Let's just say that we disagree on which lexical differences in
a HyTM document should be considered significant. We agree that it
should not be possible to query a topic map to find all base names
where the character 'a' appeared as a 'A'. We don't agree whether
it should be possible to find all topics in the scope 'fixme'.
 
* Steve Pepper
|
| 1. I believe that <facet>s *can* be handled in the SAM.
 
* Martin Bryan
|
| But can they be round-tripped or handled efficiently?

Have you tried?
 
* Steve Pepper
|
| 2. So can <topicmap 'addthems'>, <topic 'scope'> and <addthms>.
 
* Martin Bryan
|
| Not if, like me, you believe that scope is an any rather than an all
| scenario.

If you disagree with the SAM how can you expect this to work at all?
Surely the solution must be to fix the SAM rather than to work around
it? 

| [mnemonics]
|
| 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".

The committee agreed to do it this way in Barcelona. I argued for
leaving the mnemonics out altogether, but the others wanted to
represent them using published subjects. I bowed to their view when
they argued that 'if someone put it there they probably meant to say
something and we shouldn't throw it away, and in any case you won't
pay for this unless you actually use it'.

It seemed sensible to me then and it still does now.
 
| 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 :-))

Frankly, I have some sympathy for the view that it should be possible
to use HyTM in unstructured ways without being against the letter of
the law, but I find it very difficult to reconcile that with the fact
that we have to build all kinds of stuff on top of whatever we put
into the SAM.

The trouble is that anything we add to the SAM at the item/property
level is going to be very costly for us further down the road, and God
knows we've made this venture plenty expensive already. If we add this
stuff to the SAM then suddenly we have to be able to query it with
TMQL, constrain it with TMCL, represent it in CXTM, exchange it in
topic map fragments, represent it in the standard topic map API, and
who knows what else in the future.

Making things optional just makes everything much worse. Suddenly the
SAM is complicated by the notion of optional modules, and
TMCL/TMQL/CXTM/TMFX/TMAPI all get the same optional/required division
built into them. Or, they ignore the optional stuff, which in effect
is the same as leaving it out altogether.

It seems to me that it is the lesser evil to take a hard-line view on
what should be part of topic maps and what should not. Nobody will
stop you from doing what you want, anyway. You just won't conform to
the standard, which is no real tragedy; it just means what you don't
won't interoperate and the QL/CL/... won't work with your data.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >