[sc34wg3] HyTM as a SAM syntax

17 Apr 2003 15:37:53 +0200

* Martin Bryan
| 
| I'm not proposing to do anything twice: you seem to have
| misunderstood what a HyTime Grove is.

Or at least what you intended to use it for. :-)

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

I buy that. That is not how you've written the document now, though.
At the moment you are going HyTM-in-SGML -> SAM.

| SAM [...]  also, I hope, allows you to do conversions between HyTM
| and XTM.

Yes. That's part of the reason for having it.

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

Hmmmm. I suppose that implies that I am, too, since I agree with this.

* Lars Marius Garshol
|
| 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?

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

Well, scope has always been defined as applying to topic
characteristics. We would have to change the definition of scope to
accomodate your view of this. Do you really think that would be right?

* Lars Marius Garshol
|
| 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'.

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

I think needless topics are the lesser evil when we see this in
context, but I won't pretend to think it's an elegant solution.  The
only solution to this I really like is to use the time machine to go
back to 1999 and take out mnemonics altogether.

* Lars Marius Garshol
|
| 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.

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

It's for the very same reason, actually. To use TMQL as an example
we'd have to provide features for querying occurrences by their
linktype. If we don't put this in as a SAM property we can avoid that
since you can then query for these in terms of associations and
topics, which we will provide features for anyway. So it really does
simplify life. (Except for the poor people who actually use these, of
course, but the consensus of the committee has been that mnemonics are
deprecated and should not have been in the standard at all.)

* Lars Marius Garshol
|
| 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.

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

Sure. Defining the concept of profiles need not add too much to the
SAM, but the trouble is that you then have to deal with this when
selecting implementations, when designing the layers higher up, and so
on and so forth.

I think where we differ the most here is on how important we think
nested scopes and mnemonics are. I (and as far as I know the rest of
WG3 except you) see nested scopes as a mere shorthand with no logical
significance except as it applies to the leaf nodes, and similarly
mnemonics as a mistake in the original standard. Given that I'm not
very keen on incurring these costs for something I think shouldn't
have been there at all.

I think the line you should take if you want to change the committee's
mind on this is to come up with use cases that require that these
things be handled the way you prefer. Even so you may be met with
"that's a very contrived case" or "surely that's not going to happen
often" or even "you shouldn't do it that way", but I think that's your
best line of attack, really.

(BTW, I don't agree that any part of the TM model can be relevant to
TMCL without also being relevant to TMQL. TMQL must be able to reach
all parts of the model that TMCL can reach, though TMCL need not
necessarily be able to go everywhere TMQL can.)

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

Well, as regards facets the people who went through the XTM
enlightenment see those as an awkward solution to something XTM does
much better through subject addresses. We'd rather see facets mapped
to the superior XTM solution than pull a HyTM construct that is now
seen as obsolete into the model we will take with us forward into the
future. 

I realize you take a different view and I'm not sure what to do about
it. I think this is why Steve Pepper proposed an afternoon meeting
with you in London so that we can make an effort to share the XTM
enlightenment with you and also to hear your arguments in full to see
if we can resolve this.

Welllllllll. You're assuming the language will work a particular way
now. You're also assuming that the committee thinks it is OK for
people to use mnemonics. I'm not sure either of those assumptions will
hold up in practice. There's also TMQL, canonical XTM, and fragments
to consider.

Again, if I thought mnemonics were a good idea I'd take a completely
different line when discussing this (as I'm sure would the rest of the
WG3), but I don't.

| Optional facet and mnemonic elements can be added to the syntax for
| the languages, 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)

Sure, it could be done. The question is whether we want to add support
for mnemonics to four new standards built on top of the SAM when we
think it was a mistake to put them into HyTM in the first place. My
preference is to pull out the scalpel.

* Lars Marius Garshol
|
| 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;

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

Not sure which part of the view it is you are unhappy with. This is
not my opinion alone if that is what you mean. (If that is what you
meant I agree with you. Lars Marius Garshol does not hold dictatorial
power, nor should he.)

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