It has yet to be proven that the wanted design is actually implementable in a realistically efficient and clean fashion. That is, it has been implemented, but not tested on a large scale. What could cause problems is that we actually implement a distributed relational database, which very well may cause problems (not least with performance) we were not aware of when designing the system. In particular, the search functions have not been satisfyingly studied.
The requirements described for the design places strong distributability demands on the concepts, and therefore marks a real departure from UML. UML, even though it deals with the logical information in diagrams, does not deal with the problem of distributing the logical information, but only with how to combine it visually.
In contrast, the design taking form here is primarily a logical design. Concepts do not have specific visual attributes, and are not placed in a specific concept map. Therefore, the role of UML is to provide inspiration for the elements of the logical design of concepts and specifications for the visual design of concept maps. But inspiration for distributability must be found elsewhere, such as the MOF.
The Meta Object Facility (MOF) is a proposed standard for meta-models developed by the OMG in cooperation with several large software vendors. A meta-model is in essence a modeling language such as UML, and the MOF has a similar scope to that of UML. As described in [mofspec], the main purpose of the OMG MOF is to
provide a set of CORBA interfaces that can be used to define and manipulate a set of interoperable metamodels.
In practical terms, the MOF is a distributed modeling language, much like what we want to design. The MOFs initial purpose is to be used in object oriented analysis and design (similar to UML), but the OMG expects the MOF to be used to model other information systems. So the question arises: why not use the MOF? This question demands a lengthy discussion. There are several problems with the MOF that makes it problematic to use for our purposes, the most important of which are described in the following sections.
The MOF Specification [mofspec] states that the MOF designers provide
a balanced model that is neither too simplistic (one that defines only classes, attributes, and associations) nor too ambitious (one that has all object modeling constructs as required in a general purpose modeling language like the UML). The designers have specified this model to be rich enough to define a variety of metamodels and precisely enough to be implemented in CORBA environments.
What they wanted to design was a model that would be immediately usable in object oriented analysis and design. One important part of the MOF is the MOF to CORBA IDL mapping, which makes it possible to automatically generate programming interfaces for objects described by the MOF. This means that an object described by the MOF is intended to have a well-defined programming interface.
Our purpose differs from this in that the models we want to construct are models of any thinkable concepts. Such concepts are often not specific enough to be described as objects with well-defined methods in a programming environment. So we actually want a more simplistic model that is not intended to be directly usable as a programming construct.
The MOF has several serious limitations with respect to their description of associations. Firstly, they only allow associations of degree two (see further the section called Architecture in Chapter 3, Neurons and Neuron Types), even though this will change in future versions of the MOF specification. Secondly, and more serious, MOF does not view associations as being very important entities on their own. As described in Chapter 3, Neurons and Neuron Types, our design allows associations to be full-fledged concepts, having all attributes the concepts of today have. We believe this is a fundamental flaw in MOF when it comes to usability in other contexts than object oriented analysis and design, where associations usually are of a simple character.
As the MOF design is done in CORBA, the MOF describes a network of interconnected objects. There are serious problems with using this directly as a basis for a project like ours. The main problem is that MOF objects are directly connected to each other. This would imply serious stability problems if this was to be distributed globally. A large global network of interconnected CORBA objects is not yet feasible, even though this may be the case in the future.
The primary use of the MOF is inside a single development environment, called a Repository, and inside this Repository the objects are connected directly. The MOF specification [mofspec] does allow references to other objects in other Repositories, but notes that
which is a position that we simply cannot accept for Knowledge Patches, which must be designed with the primary purpose of being used outside the Patch, interconnected to other Patches.it is recognized that the great majority of these object interactions will remain within one vendor's boundary
Our solution is to let the objects reference each other indirectly via identifiers, and to be independently distributed. In spite of this, nothing stops us from designing the objects in CORBA, using the CORBA Naming Service for locating components, and even letting certain CORBA objects be connected directly, maybe even being MOF objects. But this must not be the primary design philosophy.
Another issue is CORBAs heavy-weight profile. By allowing the distribution of objects packed in XML documents, we allow lighter operation of the whole system, especially when distributed passively over the Web.
We needed a simple implementation that would give us the relevant ideas for the future of this project. Implementing the system using MOF would distract us from fundamental design issues that arise when trying to model the mental abstractions of the human mind.
By using our own implementation it is possible to give a concrete form to our objectives and how they differ from the objectives of both the MOF and UML.
Thus, we have concluded that the MOF is not optimal to use for our project. However, the overall tendency towards componentification, object oriented modeling, and information distributability give us hope that there will be a suitable generalization of the MOF available at some time in the future.
What we have designed can be described as a generalization of the MOF in the directions of
usability outside programming environments, more precisely for the modeling of human knowledge in general,
distributability, and
ability to present parts of a very large model in small diagrams
Additionally, nothing should prevent us from interacting with the MOF. Importing MOF models should be relatively straightforward and could probably be made on-the-fly using CORBA wrapper objects or XML exporters. Even importing parts of the concept world into a MOF model should be feasible using, for example, an XMI exporter. See the discussion in the section called Design Discussion in Chapter 8, The XML binding.
CORBA::RelationShips is another standard interesting as inspiration. Being designed by the OMG and described in [corbarelationships], it is a CORBA interface package containing a standardized API for accessing objects and their relationships, that in some ways resembles our configuration of related concepts. It has several advantages over the MOF, the most important of which are:
No object oriented analysis and design fixation. Indeed, CORBA::RelationShips has been used in an early attempt by IMS to describe learning resources (which is very close to our objective).
No modeling limitations. Relations of any degree can be described, and relations are given a primordial role in the system.
Relatively easy implementation thanks to its more simplistic approach.
Why is is not used by us? There are two important reasons:
It is designed more for relationships between physical resources than for representing knowledge. With this package, you describe the relations between objects external to the system, which is a motive that differs slightly from our primary motive, which is to describe relations between objects inside the system.
It suffers from the same distributability problems as the MOF, thanks to its connected CORBA object nature.
But CORBA::RelationShips is, in fact, not at all far from the design we want. It has been a direct influence for the present design when it comes to how to represent relations. What we have designed is in principle the design of CORBA::RelationShips with three important changes:
Making the system independent from CORBA in order to facilitate the wished level of distributability.
Making the system more self-contained, in the sense that the relations are between objects inside the system.
Adding data to the nodes in the system.
It is obvious that it will be an important inspiration for the design of the CORBA binding.