[sc34wg3] Documenting merging rules in TMDM

[Steve Pepper]

* Patrick:

| > Answers to my questions in your capacity as leader and
| > spokesperson for the US National Body, I hope? :-)
| > 
| Too early in the weekend for that sort of responsiblity. :-)

Fair enough, but I really hope you will answer them.
Will you?

| > But are you saying that you would accept Kal's approach, even
| > though it delegates responsibility for defining how to document
| > merging rules to TMCL?
|
| No.
| 
| Kal's approach is forced by the limitations of the TMDM that you note 
| below.

Why do you regard this as a limitation? Doesn't it make
eminent sense to delegate expression of merging rules to
the part of the Topic Maps standards family that is
concerned with constraints?

| If one follows the TMDM, then Kal's suggestion may be a good fix.

"If one follows the TMDM"...

So, for people who want to follow the TMDM, it's OK to use TMCL to
express merging rules.

...but you voted not to approve the TMDM on the grounds that it does
not have a mechanism for specifying merging rules.

Which is it? Do you want the TMDM to have that capability or don't
you? If so, what *kind* of merging rules do you mean?

| (still have the problem of vendor lock by embedding merging rules
| in software, even if Kal's suggestion is a good theoretical answer
| to the documentation problem)

What? Kal's suggestion means that the rules would be defined in the
TMCL schema, in an open, standardized manner. What does that have
to do with vendor lock? (Please try and answer this precisely
because as someone who has devoted himself to promoting topic maps
out of intellectual conviction - but is also a vendor - I am very
sensitive to the use of such arguments. I have ceased to communicate
with at least one person because of it :-)

| If one departs from the TMDM, then Kal's suggestion, to the extent that 
| TMCL follows the TMDM, is less useful.

If one departs from the standard data model there is little that
a standard can do to help, in my opinion, but this is a separate
issue. Let us try not to confuse them. The first thing to clear
up is

  What does the TMDM need to do (if anything) in order to satisfy
  the requirement to be able to document merging rules?

Kal and Dmitry have both answered "nothing", because the job is
better done by TMCL. I tend to agree with them. The US National
Body, based on its comments in the ballot, seems to think that the
TMDM needs to have this capability itself. Is that the case or
is it not?

| As you say, the TMDM limits the values of X that I can talk about for 
| both A and B, and it does not cover "X is true of A and Y is true of B."

Neither does it cover "X is true of both" for anything other than

  X = (same name of same type) | (same occurrence of same type).

However, this is simply a generalization (and "optionalization") of
the old topic naming constraint, which the majority of the committee
wanted to do away with. It was never intended to cover arbitary
merging rules, only those that correspond to OWL's "unique-property".

| Whether we will eventually agree on the details of those limits remains 
| to be seen, but I see them as being imposed by a particular 
| implementation strategy and not inherent in the nature of topic maps. Do 
| you disagree?

We ought to be able to agree on the details of the limits, because
if we can't it means that the standard doesn't specify them clearly
enough. (Either that or you and I are not smart enough.)

I don't understand what you mean by "a particular implementation
strategy". Can you be more explicit?

That applications *need* to apply additional rules in certain
circumstances is beyond any doubt (we do it all the time in our
applications). I've given some examples in my original posting.
Are they sufficiently representative or do you have more?

Steve

--
Steve Pepper <pepper@ontopia.net>
Chief Strategy Officer, Ontopia
Convenor, ISO/IEC JTC 1/SC 34/WG 3
Editor, XTM (XML Topic Maps 1.0)