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

Dmitry sc34wg3@isotopicmaps.org
Sat, 3 Apr 2004 13:44:34 -0500

On Apr 3, 2004, at 11:53 AM, Jan Algermissen wrote:

> Robert Barta wrote:
>> On Sat, Apr 03, 2004 at 12:43:25PM +0200, Jan Algermissen wrote:
>>> Jan Algermissen wrote:
>>> Consider this:
>>> Organization A has developed a topic map with specialed merging rules
>>> (e.g. merging based on latitude and longitute properties) and likes 
>>> to
>>> hand this map to another organization (or maybe even to another 
>>> department).
>>> Given your scenario, A needs to send the map, the Astma rules and the
>>> rule engine because without these three things the original intention
>>> cannot be communicated.
>>> Besides the open-source-ness of the engine in this situation this is
>>> what you actually call vendor lock-in.
>> Absolutely  correct. This is the reason  why I  think that TMCL should
>> allow me to specify these things. It should be an 'ontology definition
>> language',
> Right! And the RM provides the foundations to define TMCL. It answers 
> the
> question what a TMCL-defined ontology must contain. In the sense you 
> use
> ontology here it has the same meaning as 'Application' in the RM
> ( http://www.isotopicmaps.org/TMRM/TMRM-latest-clean.html#parid3255 )

I think that TMCL does not require RM infrastructure to manage 
identity. It requires only one mechanism - ability to explicitly 
specify that two constructs are the same. Using RM terminology, it is 
sufficient  to have just one standard SIDP to build merging theory.

All merging theories  can be expressed using this standard SIDP and 
additional axioms (merging rules).

> And the TMDM modulo the infoset part is the standard ontology for
> Topic Maps (what is a name, what is an ocurrence, what is the nature
> of the property 'SubjectIndicators' etc.)
> I have allways understood the term SAM to mean Standard Application 
> Model
> in the RM sense of 'Applicaton' which equals 'ontology', anyway.

Right, TMDM now has two pieces combined together. Standard ontology 
(without merging rules) and standard merging rules.

I think  that there is no need to replace standard ontology (without 
merging rules) with low level constructs to formally describe and 
analyze TMDM merging theory. It is sufficient to have TMDM-R(elaxed) 
and explicitly specified merging axioms using "deductive system"