On Different Interoperability Modes in Software Engineering : the Case of Modeling Activities at OMG. Jean Bézivin LRSG - Laboratoire ModélisAction Université de Nantes Faculté des Sciences et Techniques 2, rue de la Houssinière BP 92208 44322 Nantes cedex 3, France tel. +33 (251) 125 813
[email protected] http://www.sciences.univ-nantes.fr/info/lrsg
ABSTRACT OMG is mainly famous for its CORBA and IDL activities. In the various working groups of this organization, many different themes are however studied, with the same industrial consensus process that has made the success of CORBA, IDL, IIOP and many other middleware recommendations. Some of the outcomes of these efforts have already gained an important notoriety, like the Unified Modeling Language UML and its associated constraint language OCL. Others like the MOF (Meta-Object Facility, [Crawley 98]) are still less popular but already serve as recommendation basis for a lot of defined and forthcoming normative recommendations for products and processes. This paper discusses some of the running activities at OMG in domains linked to modeling. The main thesis presented here, is that OMG is now centering its activities not only on one interoperability bus, but on two different but related buses: the classical CORBA software bus and the emerging MOF semantic bus. Some illustrations of this recent evolution will be described.
serve as recommendation basis for a lot of defined and forthcoming normative recommendations for products and processes. This paper discusses some of the running activities at OMG in domains linked to modeling. From these examples, some conclusions may be drawn: •
on the high quality and stability of the global OMG decision process, allowing to detect the areas of industrial research arriving to maturity, and then to create a consensus,
•
on the success of this mechanism in the middleware field and on its present deployment in the modeling area,
•
on the essential business of OMG, namely interoperability; to the “plumbing” interoperability in the middleware business achieved with CORBA, IDL and IIOP, other more semantic forms of model interoperability are presently emerging,
•
on the practical form of modeling consensus that use to happen at nearly each OMG meeting, and the fact that they correspond usually to meta-model alignments, the mechanism of these alignments being based on the MOF.
Keywords Ontologies ; Meta-modeling; Model engineering; Process engineering ; UML; MOF; Introduction
Interoperability modes.
The main contribution of this work is to start a first OMG is mainly famous for its CORBA and IDL classification of interoperability modes. Although very activities. In the various working groups of this preliminary, this classification is based on observed work organization, many different themes are however studied, in progress at OMG. The long term goal of this research with the same industrial consensus process that has made is to progress towards a more significant taxonomy of the success of CORBA, IDL, IIOP and many other these interoperability modes and a better characterization middleware recommendations. Some of the outcomes of of their properties. A good understanding of this subject these efforts have already gained an important notoriety, is central to the definition, in the software engineering like the Unified Modeling Language UML and its field, of migration paths and strategies from old associated constraint language OCL. Others like the MOF procedural technology to new object and emergent (Meta-Object Facility) are still less popular but already ___________________________________________________________________________ Software Engineering'98, Paris, December 1998
page 1.
component technologies. A very rough classification may separate code interoperability and more general model interoperability while the latter may in turn be decomposed in product and process considerations. Introducing Models, Meta-Models and Ontologies. Much work has been done on the different aspects of logic but we still miss a useful theory of models, applicable to our practical software engineering products, processes and artifacts. This need is becoming urgent. In the recent emergence of UML as an industrial standard [OMG/UML 1997], few have noticed the underlying goal of defining not a programming, an analysis or a design notation for object or components, but really a "modeling" notation which is much more ambitious. As a matter of fact the state of the art is very rapidly moving in industrial circles. There is no doubt today that OMG is now centering its activities no more on one but on two different interoperability buses (Figure 1). The first one, the classical and historical software bus of the OMG is the CORBA bus, with some related recommendations like the IDL interface description language and the IIOP protocol. The second one, much more recent and still fragile, is the MOF semantic bus. The MOF (Meta-Object Facility) has taken much inspiration from CDIF [OMG/MOF 1997]. The importance of model engineering in the software development process is rapidly growing. Models are defined (constrained) by meta-models that we will call here ontologies.
shifted and the self defined MOF has become the reference meta-meta-model at OMG. Consequently other products are being defined in term of the MOF (Figure 3). Not only UML, but also potential extensions of UML like a considered "UML for Business Objects" notation could be defined in terms of the MOF. Entity, Relation, Package
Meta-Meta-Model
Meta-Model
Class, Method, Attribute, Component
M2
Model
Customer, Provider, Bill
M1
Exemplary
J.M. Pendibidu Ducros Inc.
M0
Figure 2 : The four level architecture.
Interesting ideas, like the OCL (Object Constraint Language) proposed at level M2 are being moved to level M3, recognizing their potential usefulness outside the strict domain of object analysis and design. Similarly, efforts that were envisioned for UML are being shifted up to the M3 level, like the serialization of models (SMIF). This intense activity has occurred in a very short period, but had been prepared by the long term effort of active communities like the CDIF group. (a)
(b)
(c)
UML
MOF
MOF
UML
MOF
aModel
UML
Java
CORBA, IDL, IIOP, ... Cobol UML
MetaData
aModel
MOF UML UML_FBO
aModel
MOF, CDIF, UML, XML, ... Workflow
M3
PWG
Workflow
etc.
Common Warehouse Metadata interchange RFP
RFP action language
Software Process
Figure 3 : The self-defined MOF. Figure 1 : The two cultures of OMG.
It is interesting to notice that in the new double vision of OMG, as illustrated in Figure 1, all efforts are being made to establish a correspondence between the software bus and the semantic bus. This means that many MOF-based recommendations have an IDL specified API. Less frequently, some CORBA-based recommendation have sometimes a UML or MOF based description. The four-level architecture (Figure 2), very familiar to the CDIF or the IRDS communities, has been accepted as an architectural framework for models, meta-models and meta-meta-models. Initially some products proposed selfdefinitions, as UML with its meta-model describing UML in UML [OMG/UML 1997]. Progressively emphasis has
Of course, what appears clearly now is the contradiction between Figure 2 and Figure 3. If we wish to define a given ontology called for example UML_FBO (UML for Business Objects), the relation between the ontological spaces UML_FBO and UML is definitively not the same than between UML and MOF. In one case it is a basedOn(UML, MOF) relation meaning that the MOF is the meta-model of UML whereas in the other case it is an extends (UML_FBO, UML) relation meaning that the ontological space UML_FBO is an extension (a superset ) of UML. Since we can only add concepts and relations, the more realistic solution would be to consider a basic ontological space called Minimal_UML, not including elements that are not likely to be useful for business
___________________________________________________________________________ Software Engineering'98, Paris, December 1998
page 2.
objects (e.g. deployment views ) and to consider UML and UML_FBO as extension spaces of Minimal_UML.
organization of composite models, in regard to the corresponding composite meta-models.
So, the example situation described in Figure 4 shows the following relations:
For all this organization to work properly, what we need most is a well defined modularity concept. There may be some misunderstanding here. What we need is not the modularity concepts that have been elaborated by the programming language and compiler communities in the last thirty years. We don't need the ADA or Modula package or the namespaces with the classical import/export def/ref semantics. What we need is more close to some notion of context, but the knowledge representation community has not yet converged to a satisfactory consensual definition. For lack of common basis let us call space what CDIF calls a subject area, what sNets call a Universe [Bézivin 94] or what UML calls a package.
• basedOn (MOF, MOF); • basedOn(Minimal_UML, MOF); • extends (UML_FBO, Minimal_UML); At the same time, other ontologies may be defined, and among them product ontologies and task ontologies [Chandrasekaran 98]. Figure 4 below shows an example of relation between the product ontology UML_FBO and the task (or process) ontology PUML_FBO.
basedOn
MOF basedOn
basedOn relativeTo
Minimal_UML
extends
PMinimal_UML extends
UML_FBO
relativeTo
PUML_FBO
Figure 4 : Relations between product and process ontologies.
Some Definitions. As previously suggested, in the present paper, the word "ontology" [Kayser 98] will be used in an interchangeable way with "meta-model" for defining a set of concepts and relations between these concepts used in a particular modeling activity. From a given system we can extract a particular model with the help of a specific ontology. If, as an example, the system is a conference, the ontology could have {Participant ; Presentation} as its set of concepts and {listenTo [Presentation, Participant]; authorOf [Presentation, Participant]} as its set of relations. The model extracted from the SE'98 conference with the help of this ontology may serve to know the participants that have presented a paper and attended at least one presentation of another participant that did not attend their own presentation. The question of how many attendees at the conference were wearing pink jackets can't be answered with a model based on the proposed ontology. So the basic use of an ontology, is that it facilitates the separation of concerns. When dealing with a given system, you can observe and work with different models of this same system, each one characterized by a given ontology. Engineers using CDIF, UML, RM/ODP, etc. are well aware of this. Obviously when several models have been extracted from the same system with different ontologies, these systems remain related and to some extent the reverse operation may apply, namely combination of concerns. What we need for that is a clean
A model is a space; a meta-model is a space; a metameta-model is also a space. This is why this notion of space is so important. If we analyze most of the metameta-model proposals that have been recently documented (MOFs, miniMOFs and similar constructions), they consist nearly always of the three basic notions {concept, relation, space}. The problem with most MOFs is that they add unnecessary entities at this level. Minimality is essential in a MOF. The fixed point relation basedOn (MOF, MOF) presented in Figure 4 is important. However, in Figure 3.a, we saw that, initially UML attempted to follow the same lead and that UML meta-model was the expression of UML in UML. The interesting question is then obviously : "which precise elements of UML have been used for this selfdefinition?". The answer for UML was "only a small part". The same question deserve to be asked about any MOF and particularly about the OMG's MOF. The problem of what is a really minimal MOF has been addressed in many research work (e.g. [Bézivin 94]) and is related to the definition of top-level ontologies ([Gruber 93]). Space MX P
R
meta
meta
Q
basedOn
meta
r q
p
Space X
Figure 5 : The real nature of a meta-model.
In Figure 5 there are two spaces represented, a model X and a meta-model MX. For each entity present in X, there is a corresponding meta-entity present in MX. The relation r (p, q) is defined in X, but the concepts P and Q and the relation R are defined in MX. The relations meta
___________________________________________________________________________ Software Engineering'98, Paris, December 1998
page 3.
(p , P) and meta (q , Q) hold. MX is the ontology of X and this corresponds to the relation basedOn (X , MX). A classical error is to consider that the relation meta (X, MX) holds, which is obviously wrong. Ontology Engineering at Work. The need to provide precise semantics for models and meta-models is rapidly arising. This follows the recognition that meta-models now often come separated and that it should be possible to associate precise constraints to the various entities and relations present in these meta-models. As an example of this situation, we may consider the OIM Microsoft recent product [Microsoft 98]. The OIM (Open Information Model) is to support tool interoperability via a shared information model, across technologies and across companies. The OIM is designed to encompass all phases of a project's development lifecycle, from analysis through deployment. The corresponding Microsoft Repository Architecture may be pictured as in Figure 6. It is interesting to remark that the Microsoft model architecture is also based on a meta-meta-model. It is called RTIM (for Repository Type Information Model) and, although information on it is rare, it is quite likely conceptually similar to the OMG MOF. The RTIM proprietary meta-meta-model is implicitly used in the various meta-models of Figure 6. So, once again, we may notice this symmetry between the evolution of affairs at OMG and in the Microsoft world.
later. Dtm is a Data Type Model, a set of Uml extensions for common data types, Cde (Component Description Model) describes generic executable components, Gen a set of general-purpose interfaces, Dbn a set of generic database concepts, Ocl a set of Oracle specific extensions to Dbm (not related at all with the OMG OCL object constraint language), Tfm a description of movement operations on data between databases, etc. Some modeling activities at OMG To take a first example of application of MOF-compliant technology at OMG, one may look at the CWMI request for proposal (Common Warehouse Metadata Interchange) [OMG/CWMI 98]. As stated in this RFP, one of the most important aspects of data warehousing is metadata. Metadata is used for building, maintaining, managing, and using the data warehouse. Unfortunately, the proliferation of data management and analysis tools has resulted in almost as many different representations and treatments of metadata as there are tools. To solve the data warehouse metadata problem, since every data management and analysis tool requires different metadata and different metadata model (known as meta-model), it is simply not possible to have a single metadata repository that implements a single meta-model for all the metadata in an organization. Instead, what is needed is a standard for interchange of warehouse metadata, that is compliant with the MOF (and the UML notation when a graphical notation is required).
The entities shown in Figure 6 represents meta-models or ontologies and the links between them defines dependencies. In this particular case, an ontology is composed of interfaces and classes. A dependency link from ontology A to ontology B means here that interfaces in A may inherit interfaces in B or that classes in A may support interfaces in B.
M OF M e ta-M e ta-Mode l
U nifie d M ode ling Language M e ta-M ode l
OA&D Mode l
Uml Uml
Gen Gen
C ommon Ware H ouse M e ta-M ode l
Dtm Dtm
W are H ouse M e taD ata
Umx Umx
Figure 7 : Common WareHouse MetaData Interchange Dbm Dbm
Cde Cde
Sql Sql
Db2 Db2
Ocl Ocl
Tfm Tfm
Olp Olp
Com Com
Figure 6 : Information Model dependencies in the MS/OIM
The nature of Microsoft ontologies represented in Figure 6 is rather unusual : Uml (only the first letter capitalized) stands for the initial UML version 1.0 defined at OMG. Umx is Microsoft own extension of UML, taking into account, for example, some extensions of UML 1.1 and
Another important effort is related to the SMIF RFP (Stream-based Model Interchange Format). The story went on approximately as follows. First there were this huge number of object-oriented analysis and design methods. The reaction was to agree on a common unified method. Since this was not found to be a realistic goal, the goal shifted to the definition of a common modeling notation, which came out nicely with the UML proposal. Then there were requests for exchanging UML models. The first answer was to suggest using CORBA as an exchange framework. Then some looked for more practical ways to do this and suggested this stream-based model interchange format. The idea came out to use XML (eXtended Markup Language) as the basis syntactic vehicle for exchanging models. As a response to the
___________________________________________________________________________ Software Engineering'98, Paris, December 1998
page 4.
SMIF RFP, XMI was presented in June 1998, at the Orlando OMG meeting. XMI (XML MetaData Interchange Format) specifies an XML-based open information interchange model, no more only for UML models, but more generally for MOF-compliant models. It may be anticipated that this technology will stabilize in the first months of 1999, since working prototypes have already been demonstrated by companies like Unisys, Oracle and IBM, at the Burlingame OMG meeting, in November 1998. The previous descriptions of UML, CWMI, SMIF, XMI and others ([OMG/Action 98], etc.) suggest an intense activity in the field of product modeling at OMG. This has happened in a very short time frame and it may be anticipated that the scene will rapidly evolve in the coming months. The relation between meta-models and XML DTD's is one of the basis of the current technological evolution. Other important moves will probably follow the definition of component-based, business object and business rules spaces. The notion of component for example has a sufficient number of different facets [Ssyperski 98] to benefit from an ontology-based definition. But in addition to product modeling, there is also an important activity going on at OMG in the field of process modeling. This activity is also usually MOF-based.
process-definition, workflow-event, resource, decision, goal, etc. One of the paths that that have been followed [OMG/Workflow 1998] was to consider a "base workflow meta-model" on top of which more sophisticated, higher level meta-models could be constructed like several enterprise workflow metamodels, role workflow meta-models, etc. It is reasonable to think that subsequent work in the fields of workflow definition or software process definition will be based on hierarchies of related meta-models. It is even conceivable that software process meta-models and workflow meta-models may share some common foundation, similar for example to the PIF (Process Interchange Format) pictured in Figure 8 [Lee 96]. Entity
-
Should the facility specify work products, rules for producing the work products, and the relationships among the workproducts?
-
Should the focus of the facility be the whole software development process or should it be limited to some part of it such as analysis and design?
Resource
Decision Skill
Uses
Creates
Modifies
Performs
Actor
Successor Group
Modeling products and processes In November 1998, a RFI (Request for Information) has been launched on the subject of SPE (Software Process Engineering) by the OMG Analysis and Design Task Force. This is an important step, complementing the initial UML notation proposal. It may be anticipated that the answer will come in the form of suggested MOFcompliant meta-models of generic processes using UMLbased artifacts. Among the questions that should be answered in this RFI, we find for example the following ones:
Relation
Activity
Prerequisite
Cannot-be-concurent
Figure 8 : Basic entities in the PIF model
The basic entities of the PIF core meta-model are themselves related by basic relations exemplified by Figure 9 below. The PIF mcore meta-model is itself based on the KIF (Knowledge Interchange Format, [Genesereth 92]). Another alternative would have been the NIST UPSL (Unified Process Specification Language, [Schlenoff96]).
P re re q u is ite
-
The n S u c ce s s or
a ctivity
S u ccesso r P red e ce sso r
Is a meta-model sufficient to support "plug and play" software development process definition from components?
-
Should the facility have the capability to provide standard patterns to support the project profiles?
-
Are the UML and MOF sufficient to define the Software Process Engineering meta-model?
These questions are characteristics of the direction the SPE work is going on. There is however another field that has been very active at OMG in the last period: the workflow definition [Schulze 96]. The basic considered concepts in the meta-models could be for example workitem, skill, participant, risk, group-of-participants,
D e c is io n
R e q u ired -activity
Gro u p
Acto r
Else
Activity
C re a te s
C o m po n e nt S kill
P e rfo rm s
Mo d if ie s
R e s o u rc e
Figure 9 : Some relations between PIF entities
On the variety of model spaces
We have seen in the previous sections a big number of different spaces, that are recognized to be important in the information system field (see Figure 10 as an ___________________________________________________________________________ Software Engineering'98, Paris, December 1998
page 5.
example). Each such space is characterized by its metamodel. There are many relations between different spaces. We have composite spaces as well as derived spaces. The unicity of the meta-meta level is important for expressing these space relations. The choice of OMG on the MOF meta-meta notation will become central to express product models, process models and also all the relations between these process and product models.
design model
business model workflow
domain usage
a
c
b coding model
e d
g
f
Figure 10 : Composite spaces in software engineering.
In addition to a general theory of spaces and space representation on which we have argued here, there is the beginning of a theoretical work on the nature of the various models present in the new object-oriented development cycle. We may recognize how such a theory is badly missing when we see the time spent on discussing the real meaning of business objects and their differences with technical objects. The basis for such a work may be found in the vision of the system as the intersection of a domain space (the world) and a ressource space (the machine) as presented for example in [Jackson 95]. Conclusions. Ontology engineering corresponds to the activity of dealing with meta-models. This activity has become much more common in the recent period. It should be based on a clear set of techniques and principles. Some of the lessons learned in the course of practical work at OMG and in similar places may be summarized as follows. Ontology engineering is becoming a daily activity in many circles. This activity takes many forms and many names, for example Meta-model alignment. It is likely that this emerging area will become much more active in the coming years or even months. The problem of dealing with different syntax and semantics is one of the main challenges of our corporation. There are presently two views of the technology world. One is the optimistic/unified view that states that we are going to converge towards one unique operating system (e.g. Microsoft's Windows NT) or one unique language (for example Sun's Java), or one unique database system (name it), etc. The other one is the pessimistic/realistic view of the OMG that states that the only consensus is that there will not be any real consensus in these areas. The conclusion then logically follows that we should
prepare to face in the future, as efficiently as possible, the multiple challenges of interoperability as one of the main characteristics of our work in the computer science arena. Of course many had not waited the creation of OMG to discover that. The CDIF community, the ASN.1 and more generally the network community and many others had already proposed ways to survive in the heterogeneous technological jungle. However a lucid look at the recent evolution may be of some help here. Object technology has recently replaced procedural technology and brought many benefits, mainly reusability and reliability. One of the promises of object technology has however not be honored: unification. Some people initially claimed that, because we were using objects everywhere, the technological dialog would be much simplified. In reality the reverse occurred1. One discovered with surprise that it was much more difficult to translate a real application from C++ to Smalltalk than it was before to transform the same volume of code from Fortran to Pascal or to C for example. The reason is that, beyond the surface unification of objects, there are deep semantic differences between various object schemes. So, one of the identified problems for the development of the object technology was the lack of portability across different languages. As a reaction OMG developed the CORBA software bus and the IDL language. Another arising problem identified by OMG was the huge number of emerging OA&D (object analysis and design) methods (more than fifty were counted at one time). The reaction was to create a consensus not on the methods themselves, but only on the notation. This resulted in the UML standard [OMG/UML 97]. This had also the consequence of bringing the OMG from the field of code interoperability to the more general problem of model interoperability. Although UML was, and still is, a good industrial solution for the OA&D area, other areas like workflow were also looking for suitable notations in the form of meta-models. How to synchronize all these new emerging meta-models was then the next challenge at OMG. Building on internal as well as on external work like the CDIF community findings, OMG proposed a common meta-meta-model able to unify all the existing and future meta-models, and among them obviously the UML metamodel. This was the basis for the MOF [OMG/MOF 97]. As we have suggested above, not only does the MOF allows the building of new meta-models, but it will encourage them. No doubt that this new technology will take some time to stabilize and to be completely integrated in the mainstream like CORBA, but it is now on the rails and will allow many new interoperabilty
1
One buzzword that we hear less and less is "seamlessness". Object technologists are becoming more interested in the subtle differences between object metamodels than in their similarities.
___________________________________________________________________________ Software Engineering'98, Paris, December 1998
page 6.
issues to be raised. These issues will not be artificially generated problems but will correspond to solving practical industrial concerns in the deployment of new generation information systems and specifically show how to make good usage of enterprise ontologies [Ushold 98]. The transition from object-oriented programming to ontology-driven modeling will probably be one of the most important challenge to software engineering in the coming period. Bibliography. [Bézivin 94] J. Bézivin, J. Lanneluc, R. Lemesle, Representing Knowledge in the Object-Oriented Lifecycle TOOLS PACIFIC'94, Melbourne, [December 1994], Prentice Hall, pp. 13-24. [Chandrasekaran 98] B. Chandrasekaran, J.R. Josephson, V.R. Benjamins, Ontology of Tasks and Methods, 1997 AAAI Spring Symposium and the 1998 Banff Knowledge Acquisition Workshop [1998]. [Crawley 98] S. Crawley, S.Davis, J. Indulska, S. McBride, K. Raymond. Meta Information Management. Formal Methods for Open Objectbased Distributed Systems conference, Canterbury, United Kingdom, [21-23 July, 1997].
Management Group, Framingham, Mass., [September 1997]. [OMG/SPE 98] OMG Analysis and Design PTF, Software Process Engineering Request for Information, Version 1.0, OMG Document ad/98-1008, [13 November 1998] [OMG/UML 97] OMG/UML Unified Modeling Language UML Notation Guide. AD/97-08-05, Object Management Group, Framingham, Mass., [November 1997]. [OMG/Workflow 98] OMG Workflow Management Facility Specification OMG Document bom/98-0111, [1998] [Raymond 97] K. Raymond Meta-Meta is BetterBetter. IFIP WG 6.1 International Working Conference on Distributed Applications and Interoperable Systems [ September/October 1997]. [Schlenoff 96] C. Schlenoff, A. Knutilla, S. Ray, Unified Process Specification Language: Requirements for Modeling Process, NISTIR 5910, National Institute of Standards and Technology, Gaithersburg, MD, 1996.
[Genesereth 92] M. Genesereth and R. Fikes, Knowledge Interchange Format Version 3.0 -- Reference Manual, Logic Group Report Logic-92-1, Stanford University, 1992.
[Schulze 96] W. Schulze, M. Böhm, K. Meyer-Wegener: Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments, OOPSLA 96, Workshop on Business Object Design and Implementation, San José, CA.
[Gruber 93] T. R. Gruber. Toward principles for the design of ontologies used for knowledge sharing. Presented at the Padua workshop on Formal Ontology, [March 1993].
[Szyperski 98] C. Szyperski, Component Software : Beyond Object-Oriented Programming Addison Wesley, [1998].
[Jackson 95] M.A. Jackson, Software requirement & Specifications A lexicon of practice, principles and prejudices Addison Wesley, ACM Press, [1995], 228 p.
[Uschold 98] M. Uschold et al The Enterprise Ontology, The Knowledge Engineering Review, Vol. 13, Special Issue on Putting Ontologies to Use, [1998].
[Kayser 98] D. Kayser Ontologically Yours Invited Talk, ICCS'98, Montpellier, France, LNAI #1453, M.L. Mugnier & M. Chein eds, [August 1998]. [Lee 96] J. Lee, M. Gruninger, Y. Jin, T. Malone, A. Tate, and G. Yost, The PIF Process Interchange Format and Framework Version 1.1, Technical Report Working Paper No. 194, MIT Center for Coordination Science, 1996. [Microsoft 98] Microsoft, Microsoft Repository Product Information, Open Information Model Overview, http://msdn.microsoft.com/repository/prodinfo/. [OMG/Action 98] OMG/Action Action Semantics for the UML, Request for Proposal, OMG Document ad/98-11-01, [November 1998] [OMG/CWMI 98] OMG Common Warehouse Metadata Interchange Request For Proposal, OMG Document ad/98-09-02, [September 18, 1998]. [OMG/MOF 97] OMG/MOF Meta Object Facility (MOF) Specification. AD/97-08-14, Object ___________________________________________________________________________ Software Engineering'98, Paris, December 1998
page 7.
