[sc34wg3] Documenting merging rules in TMDM

[Dmitry]

I agree with Kal. I think that  merging rules can be described as  part 
of ontology expressed using TMCL.
If TM commits to ontology it commits to defined merging rules.

I can imagine that some TM software can hard-code some merging rules 
(for me it means hard-coding some ontology).
But these rules will be still expressible using TMCL if we stay on TMDM 
ground.

TMCL can express merging rules. Do we need anything else?

Dmitry


On Mar 13, 2004, at 9:21 AM, 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
> -- 
> Kal Ahmed <kal@techquila.com>
> techquila
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>