[sc34wg3] Documenting merging rules in TMDM
Sat, 13 Mar 2004 11:22:03 -0500
Steve Pepper wrote:
> * Patrick:
> | Just a quick reply with more to follow.
> 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. :-)
> | There is a difference between:
> | 1. Merging rules written in a known syntax (your case)
> | and,
> | 2. Merging rules that are embedded in an application.
> | The first allows a customer to make a reasoned judgment of cost and risk
> | in migrating from one topic maps software application to another.
> | The second does not.
> | Does that help?
> Help in which way? I agree with this entirely, so it establishes
> that we are on the same page in that regard: Documenting merging
> rules is preferable to not documenting them.
> 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?
Kal's approach is forced by the limitations of the TMDM that you note
If one follows the TMDM, then Kal's suggestion may be a good fix. (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
If one departs from the TMDM, then Kal's suggestion, to the extent that
TMCL follows the TMDM, is less useful.
> | (Curious why I need TMCL to express: "X is true of topic A and Y is true
> | of topic B then topic A and topic B must be merged." The TMDM already
> | has 'X is true of topic A and X is true of topic B then topic A and
> | topic B must be merged.' Is there some reason why I need a separate
> | mechanism for X and Y? Other than a particular implementation strategy?)
> Well, you said it yourself. The TMDM allows you to express "if X is true
> of *both* A and B then A and B must be merged" (at least it does so for
> certain values of X, although not for all). But it does not allow you to
> handle "X is true of A and Y is true of B". Ergo you need something in
> addition. In Kal's view: TMCL.
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."
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
Hope you are having a great day!
> Steve Pepper <email@example.com>
> Chief Strategy Officer, Ontopia
> Convenor, ISO/IEC JTC 1/SC 34/WG 3
> Editor, XTM (XML Topic Maps 1.0)
> sc34wg3 mailing list
Director of Research and Development
Society of Biblical Literature
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Topic Maps: Human, not artificial, intelligence at work!