[sc34wg3] Documenting merging rules in TMDM

[Patrick Durusau]

Kal,

Just a quick reply with more to follow.

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?

(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?)

Hope you are having a great day!

Patrick

Kal Ahmed wrote:
> It seems to me that this kind of functionality could be done as part of
> TMCL. I am thinking that there could be constraints such as if X is true
> of topic A and Y is true of topic B then topic A and topic B must be
> merged.
> 
> If TMCL does indeed build on TMQL then I think that we would end up with
> a highly expressive language not only for constraining topic maps but
> also for prescribing merging rules.
> 
> Cheers,
> 
> Kal
> 
> On Sat, 2004-03-13 at 13:07, Steve Pepper wrote:
> 
>>I omitted to draw your attention to the fact that the
>>Topic Maps Data Model was recently approved as a CD by
>>National Bodies. Congratulations to everyone involved!
>>
>>There were some useful comments from Japan and the US which
>>we will have to consider. I would like to address one of
>>them here.
>>
>>The US National Body considers it to be a "severe defect"
>>that there is no means of "documenting an extension to
>>the data model for additional merging rules" in the TMDM.
>>
>>While I disagree on the severity of this "defect", I agree
>>that there might be a real user requirement here that we
>>should try to satisfy.
>>
>>In order to see how the requirement might be satisfied, it
>>would be useful to have a representative selection of the
>>kind of merging rules the US NB is talking about. Quite
>>apart from anything else, this would ensure that we have
>>the same understanding of the requirement.
>>
>>I would therefore urge everyone, and the US National Body
>>in particular, to put forward examples of the kind of
>>merging rules we need to be able to express, so that we
>>have something tangible to discuss in Amsterdam.
>>
>>To get the ball rolling, I will propose a couple of simple
>>ones myself:
>>
>>R1  Merge topics that have the same name in the same scope.
>>
>>R2  Merge topics that have identical occurrences of type
>>    'home page'.
>>
>>R3  Merge topics of type 'person' that have identical
>>    occurrences of type 'email address'.
>>
>>R4  Merge topics of type 'company' that have one or more
>>    names in common are 'located in' the same 'country'.
>>
>>R5  Merge topics that play the role of 'parent' with respect
>>    to the same topic.
>>
>>Some questions:
>>
>>Q1. Are these examples of the kind of thing the US NB is
>>    thinking of?
>>
>>Q2. How representative are they?
>>
>>Q3. What other examples can you come up with?
>>
>>Q4. What would be an example of the most complicated kind
>>    of merging rule you think the standard should be able
>>    to document?
>>
>>Q5. Should it be possible to document the rules in a
>>    formal, machine-processable manner?
>>
>>Q6. Should it be possible to express rules using criteria
>>    that are not present in the topic map to which the
>>    rules apply? (In my examples, all rules are expressed
>>    in terms of constructs in the topic map in question.)
>>
>>Q7. Should the merging rules cover the merging of anything
>>    other than topics?
>>
>>If we get answers to these questions, and a representative
>>set of merging rules, we might be able to resolve this issue
>>in Amsterdam.
>>
>>Best regards,
>>
>>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!