[sc34wg3] HyTM as a SAM syntax

[Martin Bryan]

Lars Marius responded to my:

> | 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'm not proposing to do anything twice: you seem to have misunderstood what
a HyTime Grove is.

The correct sequence is HyTime -> HyTM Grove -> HyTM -> SAM -> TMM or XTM

The grove is the formal HyTime specification of the model being used to
create the HyTM document. It allows the HyTM document to be validated
against the HyTime rules. SAM serves the same role against the Topic Map
Reference Model and also, I hope, allows you to do conversions between HyTM
and XTM.

I don't see this as doing the same thing twice. I see it as providing tools
for mapping in both directions from the HyTM core. (But then I'm hopelessly
biased!!!)

> | But can they be round-tripped or handled efficiently?
>
> Have you tried?

I have tried writing rules for the creation of topics, but not for their
application as there is absolutely no need to if you are already using XSLT
to process facets individually, which is how they can be handled simply when
being used within HyTM.

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

I would love to fix SAM so that the inheritance of scopes is properly nested
as per 13250, but do not expect to get any support for the proposal. Every
time the subject of nesting of scopes has been brought up while I've been
able to attend meetings I've been told that scope is only applicable on
final nodes in unnested sets of topics for which all values must be matched.
Unfortunately my committments to DSDL do no allow me to argue and argue with
you all.

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

Well, I agree on the "shouldn't throw it away" approach, and if it has to be
made into a topic to do that so be it, but personally I prefer to keep it as
a property of the topic rather than create needless topics for the retention
of all properties.

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

I agree that nested scopes are costly in these terms, but I can't see why
adding something like a simple facet name/value pair or a simple
mnemonic-source property with values of either GI, linktype or topic are
going to seriously extend the work of any of these proposals.

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

Why? Profiles that allow you to use subsets of models are easy to define.
While nested scopes will give problems here, the facet side is easy to
implement, and mnemonics can be introduced in the constraint language,
though I suspect they are irrelevant as far as the query language is
required.

To create a profile for managing facet processing you simply identify
whether or not facets querying is allowed by adding an attribute to the
query element that says facets="yes" or facets="no", with no as the default.
Applications that od not support facet querying can require that the default
value is never overridden.

The constraint language is as simple to handle both facets and mnemonics.
For the latter add a use-mnemonics attribute to the constraints element that
has permitted values of "none|GI|linktype|GI-linktype", with none as the
default.

Optional facet and mnemonic elements can be added to the syntax for the
langauges, along the lines:
   <facet name="xyz" value="expression A"/>
   <mnemonic type="GI" name="staff"/>
(or with the expression/name as the contents of the element)

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

Here I vehemently disagree with you. Why should someone who conforms to ISO
13250 today have to drop any features they have chosen to use just because
you want to take a hard-line view and restrict their use of an agreed
international standard? I consider such a view unacceptable.

Martin Bryan