[sc34wg3] Individual contribution on the U.S. N.B. position onthe progress ion of Topic Map standards

[Dmitry]

From: "Patrick Durusau"
To: <sc34wg3@isotopicmaps.org>
Cc: <rho@bigpond.net.au>
Sent: Saturday, April 03, 2004 7:52 AM
Subject: Re: [sc34wg3] Individual contribution on the U.S. N.B. position onthe progress ion of Topic Map standards


> Dmitry is only correct if you think subject identifier (like Humpty
> Dumpty) can mean whatever you wish for it to mean at the moment,
> undisclosed to any author or user of a topic map.
>
> In the context of the TMDM, which is, after all, a data model for XTM
> syntax, subject identifier has a specific meaning, to-wit:
>
> 3.24 subject identifier
> a locator that refers to a subject indicator
>
> [What is a locator?]
>
> 3.11 locator
> a string conforming to some locator notation that references one or more
> information resources
>
> [What is a subject indicator?]
>
> 3.25 subject indicator
> an information resource that is referred to from a topic map in an
> attempt to unambiguously identify the subject of a
> topic to a human being. Any information resource can become a subject
> indicator by being referred to as such from
> within some topic map, whether or not it was intended by its publisher
> to be a subject indicator.
>
> Dmitry's case of baseName is a good one, but not for the reason posed.

Patrick,

You are right, my example was oversimplification. My main point was that good theory of merging can be built at (almost) TMDM level.

Robert's example  http://topicmaps.it.bond.edu.au/docs/23/toc
is a good confirmation of these thoughts.

> How do I determine, based upon an examination of the syntax of a topic
> map in front of me, that Dmitry has used baseName as the basis for
> subject identity? Certainly not reflected in the syntax of the topic
> map. Not in the TMDM.
>
> Can I apply some TMCL rule as you suggest to reach that result? Sure,
> but that is determining subject identity on an ad hoc basis and not in
> terms of specifying the rules for subject identity prior to processing
> the topic map.

I am just suggesting to use "rule-based" form of declarative definition of merging rules at TMDM level.

If I were to develop "merging" theory I would not go RM route.

Firstly, I would introduce  TMDM Relaxed (TMDM-R). TMDM-R is TMDM with relaxed merging rules.

I would introduce "identity tag".  Each TMDM-R construct can have several identity tags.

I would introduce main identity axiom:

"If two TMDM-R constructs have at least one identity tag in common these constructs are identical."

I would allow defining identity identification rules. Each identity rule transforms TMDM-R instance into new TMDM-R instance with
new identity tags.

And I would allow defining merging implementation rules. Each merging implementation rule transforms TMDM-R instance into new TMDM-R
instance. Implementation rule defines what it means to be merged for a specific type of TMDM constructs.

These transformation can be described in a very formal manner.

Using these mechanisms I can (informally) describe "not relaxed" TMDM as following:

Identity Identification Rules:

IDRule 1:
If topic X1 has Subject Identifier S
And topic X2 has Subject Identifier S
Then assign X1 the same identity tag as X2
attach justification based on this rule to identity tag

IDRule 2:
If topic X1 has Address A
And topic X2 has Address A
Then assign X1 the same identity tag as X2
attach justification based on this rule to identity tag

IDRule 3:
If topic X1 has SourceLocator L
And topic X2 has SourceLocator L
Then assign X1 the same identity tag as X2
attach justification based on this rule to identity tag

IDRule 4:
If topic X1 has base name N1 in scope S
And topic X1 has base name N2 in scope S
And value of N1 is equal value of N2
Then assign N1 the same identity tag as N2
attach justification based on this rule to identity tag

...... <Other rules>


Merging Implementations Rules (they create new TM instance) :

IMRule1:

If  X1 is a topic in TM with identity tag T
and X2 is a topic in TM with identity tag T
then
retract topic X1
retract topic X2
add new topic T into TM
copy all constructs related to X1 to T
copy all constructs related to X2 to T
record fact of merging and snapshot of information about X1 and X2 for unmerging

IMRule2:

If  N1 is a base name in TM with topic X , scope S,  value V and identity tag T
and N2 is base name in TM with topic X, scope S,  value V and identity tag T
then
retract name N1
retract name N2
add new name N into TM with  scope S and value V
record fact of merging and snapshot of information about N1 and N2 for unmerging

.......<Other rules>


Dmitry