[sc34wg3] Documenting merging rules in TMDM
Patrick Durusau
sc34wg3@isotopicmaps.org
Sat, 13 Mar 2004 11:25:32 -0500
Dmitry,
Dmitry wrote:
> 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.
>
Yes, merging rules "can be" expressed using TMCL, but the question is
whether that is:
1. Required by the nature of topic maps or a particular implementation
strategy (and what are the other costs of that strategy)?
2. If rules are embedded in an application, how does a user make a
reasoned assessment of the costs and benefits of switching to another
brand of topic map software?
> 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.
>
Yes, but that is like saying you can do string matching in MySQL, so
long as you don't want to match Unicode strings. (Unicode support is
coming for MySQL, just not there yet.) So long as you confine yourself
to the limitations of a particular data model, I am sure anything
follows that model will serve your purposes. Question is: Is the
limitation compelled by the nature of topic maps or inherent in an
implementation choice that is just one among many that could be made?
> TMCL can express merging rules. Do we need anything else?
>
Expression of merging rules for topic maps (as in ISO 13250) that don't
follow the TMDM.
Signing off for a bit, will return later today (family members came to
town).
Hope you are having a great day!
Patrick
> 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
>>
>
> _______________________________________________
> 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!