[sc34wg3] Documenting merging rules in TMDM

[Patrick Durusau]

Steve,

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

Kal's approach is forced by the limitations of the TMDM that you note 
below.

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 
documentation problem)

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 
you disagree?

Hope you are having a great day!

Patrick







> 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)
>  
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> 


-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
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!