From: Roy Roebuck [roy(AT)one-world-is.org]
Sent: Monday, September 06, 1999 9:06 PM
To: 'topicmapmail@infoloom.com'
Subject: Correlation with metaschema similar to TopicMap

Follow Up Flag: Follow up
Flag Status: Flagged

Hi:

I've just joined the list.

Have there been any documented correlations between Topicmap (which appears document-centric because of its SGML roots) and other similar data- and metadata-centric methods such as the:

Object Management Group (OMG) and Distributed Management Task Force (DMTF) Common Information Model's (CIM) metaschema (http://www.dmtf.org/spec/cim_spec_v22/#_Toc453584954);

the LDAP Object Model (http://www.ldapcentral.com/);

XML/XLL/XSL and XMI (http://www.w3.org/XML/);

InfoMap Multicentric Information Map (http://www.multicentric.com/);

a Natrificial Brain (http://www.thebrain.com);

a MindMan MindMap (www.mindmanager.com);

or other knowledge representation and navigation methods?

I refer to the information that these products and methods are intended to manage as multidimensional information. See my diagram at /rer/owis/dem/slides/sld090.htm. I also describe the information products we all work with as structured, semistructured, and unstructured. Raw and unstyled text is unstuctured, as are images and sound without tags/indeces. Tagged information products are semistructured (as in XML without a DTD or DCD, in HTML, text with assigned styles, and images/audio with tags/indexing). Structured information products are tagged products (with the product "container" being the top or root tag and having some positive number of other internal tags) with a defined organization (as in a DTD/DCD, or a database or directory schema).

My own method at /rer/owis/) also corresponds to these areas. The Topicmap concept seems to provide much of the "star" portion of what I've referred to over the past 17 years as a "tree/star/arrow" model of information (/rer/owis/dem/slides/sld033.htm and attached), now most commonly recognizable as a generalized object model, which I apply to achieve what I call "Context Management" to enable "relevant situational awareness" for organizations, groups, and individual persons and mechanisms. "Relevant situational awareness" has also been jokingly referred to as "relevant omniscience", which also seems to be a goal of Topicmap.

My General Enterprise Management (GEM) tree represents an ordered hierarchy for namespace and categorization management using a root schema of my design (i.e., a superset variation of LDAP V3's X.521 schema), with freeform and inherited attributes for each hierarchy class or instance entry, with XML as the enabling technology.

The GEM star represents freeform associations between entries in the hierarchy, and freeform attributes describing the associations. This would include quantitative and chronological attributes to support general purpose and specialized "resource management" and "requirement management" functions, with XLL providing the enabling technology. A link to a "system of record", document, or other data source would provide a "snowflake" view of information around an object's tree entry or star/profile. The snowflake appears to correspond to the Topicmap "occurence".

The GEM arrow represents the "change management" function of the tree and star, whereby one could track the history of the tree and star for analytical purposes, project future tree and star changes for program/budget and strategic planning, or project situational changes for simulations and contingencies. XSL technology would provide the filtering/sorting functionality necessary to view selective portions of the information products in the required order.

Getting back to the subject or correlating these models, I'd organize a framework for the "multidimensional information product management" metaschema correlation to look something like this notional Feature/Product matrix.

 

  Product
Feature OMG Metaschema LDAP Topicmap XML/XLL/XSL InfoMap MindMan GEM Tree/Star/Arrow etc.
schema Yes Yes Yes Yes Yes Yes Yes  
class Yes Yes Yes Yes Yes Yes Yes  
property Yes Yes Yes /Yes Yes Yes Yes  
method Yes ? Yes /Yes Yes Yes Yes  
trigger Yes ? Yes Yes Yes Yes Yes  
indication Yes ? Yes Yes Yes Yes Yes  
association Yes Yes Yes /Yes Yes Yes Yes  
references Yes Yes Yes /Yes Yes Yes Yes  
qualifiers Yes Yes Yes /Yes Yes Yes Yes  


and then expand the Feature detail for each product column to include subcagetories of Function, Benefit, Standard, Mechanism, and Cost. Any feature that any one product had would be listed in the leftmost column, and then other indicators would be listed in each product's column to show whether that feature is available, planned, etc. and providing product-specific nomenclature and mechanism. I personally believe that an Excel 2000 spreadsheet, using a WebFolder for those who would prepare and contribute to the matrix, would be a good way to approach this work, or perhaps a collaborative editing session over Netmeeting or such.

Roy Roebuck
Enterprise Engineer
One World Information System
1-703-598-2351

and

Principal Information Engineer
SAIC, Global Command and Control Support

P.S.

Here's an extract from the above referenced online OMG Metaschema document used as the startpoint for the features list in the above matrix.

"The elements of the model are Schemas, Classes, Properties and Methods. The model also supports Indications and Associations as types of Classes and References as types of Properties.

A Schema is a group of classes with a single owner. Schemas are used for administration and class naming. Class names must be unique within their owning schemas.

A Class is a collection of instances that support the same type: that is, the same properties and methods.

Classes can be arranged in a generalization hierarchy that represents subtype relationships between Classes. The generalization hierarchy is a rooted, directed graph and does not support multiple inheritance.

Classes can have Methods, which represent the behavior relevant for that Class. A Class may participate in Associations by being the target of one of the References owned by the Association. Classes also have instances (not represented in Figure 2-1).

A Property is a value used to characterize instances of a Class. A Property can be thought of as a pair of Get and Set functions that, when applied to an object, return state and set state, respectively.

A Method is a declaration of a signature (that is, the method name, return type and parameters), and, in the case of a concrete Class, may imply an implementation.

A Trigger is a recognition of a state change (such as create, delete, update, or access) of a Class instance, and update or access of a Property.

An Indication is an object created as a result of a Trigger. Because Indications are subtypes of Class, they can have Properties and Methods, and be arranged in a type hierarchy.

An Association is a class that contains two or more References. It represents a relationship between two or more objects. Because of the way Associations are defined, it is possible to establish a relationship between Classes without affecting any of the related Classes. That is, addition of an Association does not affect the interface of the related Classes. Associations have no other significance. Only Associations can have References. An Association cannot be a subclass of a non-association Class. Any subclass of an Association is an Association.

References define the role each object plays in an Association. The Reference represents the role name of a Class in the context of an Association. Associations support the provision of multiple relationship instances for a given object. For example, a system can be related to many system components.

Properties and Methods have reflexive associations that represent Property and Method overriding. A Method can override an inherited Method, which implies that any access to the inherited Method will result in the invocation of the implementation of the overriding Method. A similar interpretation implies the overriding of Properties.

Qualifiers are used to characterize Named Elements (for example, there are Qualifiers that define the characteristics of a Property or the key of a Class). Qualifiers provide a mechanism that makes the meta schema extensible in a limited and controlled fashion. It is possible to add new types of Qualifiers by the introduction of a new Qualifier name, thereby providing new types of meta data to processes that manage and manipulate classes, properties and other elements of the meta schema. See below for details on the qualifiers provided."