... and what about un-merging? RE: [sc34wg3] Documenting merging rules in TMDM

[Lars Marius Garshol]

* Bernard Vatant
| 
| 1. Dmitry writes : "TMCL will require only one constraint -
| haveSameSubject"
| 
| I deeply agree with that viewpoint. IMO the standard should simply
| define the rules under which subjects are to be considered the same
| or different : distinction between SIDPs and other properties. What
| the applications will do with that, merging or otherwise, is their
| own business.

This is precisely my point of view as well, and also what the current
CD does. (Though it does not use the "SIDP" terminology.)

| So maybe the whole notion of "merging rules" is to be striken from
| the standard.

Please see the top part of my reply to Patrick for why this is not on
the cards.
 
| 2. There has always been an over-focusing on merging.  

Indeed. :)

| Un-merging has been completely overlooked, as if merging was a
| monotonous, non-reversible process. Are topics like black holes,
| that can only grow with time? Be aware that black holes eventually
| destroy about all information coming from the objects they have
| incorporated (except mass, electrical charge and cinetic momentum
| values, which does not make much).  But in knowledge management and
| science, a fundamental process is the discovery that what was
| considered so far a single subject is in fact more than
| one. Complexity growth is a process completely opposite to formation
| of black holes : it creates new information about new subjects. I
| thought all those were properties of A, but A turns out to be B and
| C and D ... that I previously all mixed together, so I now want to
| un-merge A and distribute properties between B, C, and D.
|
| IOW : do we make provision for merging to be a reversible process ?

At the moment there is no explicit provision for this. If vendors want
to add additional constructs to support it, they can. In general I
think this is an area that needs more theoretical work, and that
trying to standardize support for this or anything relating to it is
too early yet.

That it is important in certain contexts certainly is clear. I also
think this is related to TMQL: in many cases that may be the way to
implement solutions to this.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >