1. INTRODUCTION

System catalogues play an important role in relating subsystems. Nearly all catalogues today are active in the sense that they are a dynamic automatic source of naming and typing information for programs accessing the system, rather than a passive static reference. The prefix meta is often used within the discipline of interoperability to mean ‘information about’. In relational systems meta-data is the relationship between data in the schema and the constructs used (tables, attributes). Providing interoperability between one relational system and another is relatively straight-forward and there are commercial systems that provide this capability, for example Platinum Products (Computer Associates 2000). In COBOL systems, wrapper constructions are increasingly used to provide a meta-level by encapsulation of programs with pre-determined interfaces. The freeness of the object-oriented paradigm means that the meta-level needs to be constructed with great care to control the representation of classes, objects, properties, references, inheritance, composition and methods.

Considerable work in improving interoperability between object-based systems has been done by Crawley (Crawley 1997). His group developed the Meta-Object Facility (MOF) which introduces an information layer above the layers of schema information and the information itself. In their terminology, meta-information is information about objects in the form of a type schema and meta-meta-information is information about meta-information in the form of the meta-schema containing types of types and types of relationships. MOF provides a framework for managing meta-information and has been accepted by the Object Management Group (OMG) as a way forward in achieving interoperability between object systems (Cattell 2000). Work at Unisys (Ivengar 1999) also highlights progress, within the object context, in achieving interoperability using UML and MOF. In addition IBM have improved interoperability in object systems using XML (IBM 1999) which is employed in the W3C Resource Dictionary Framework project. Markup languages have the advantage of being robust data models but do not readily provide complex semantic constraints because they are essentially at the syntactic level.

However, the problem is that neither OSI, MOF or XML provide a universal basis for interoperability. They facilitate the connection of, say, one object system to another but lack a top neutral level relating constructs to universal abstractions, which would enable handling of the full range of heterogeneity, such as objects, relations, trees and data processing record-types. There is also some confusion in terminology with relational systems using the term meta as a relationship between levels and the object systems using it as a level descriptor. Web search engines perhaps typify the present usage of meta-data to achieve interoperability in a local context: IQSeek for example employs meta-data to enable users to search across a number of sites with a single request. Such a technique, applied in effect to a union of document databases, is often termed meta-searching (Gravano 1998). There is considerable difficulty in standardising output formats and retrieval rankings as each system will have its own specialist methods which may not be fully defined at the user interface. This introduces an uncertainty so that a user cannot be sure what method has led to the results obtained. Critical features may be unused and serious consequences follow if the conditions cannot be relied on with confidence.

Mediation (Wiederhold 1992) is another technique employed for enabling heterogeneous systems to communicate one with another. Mediation is typically used for linking systems which employ different models and attempts to relate schema constructs in one system to those in another. It suffers from a lack of generality with a considerable amount of manual work required to connect systems which are not closely related.

Another approach has been schema integration often involving the construction of federated database systems in which a number of independently designed databases are permitted to interact with each other. Schema integration in such cases may be an intensive human activity and Duwairi, Fiddian and Gray (Duwairi 1996) discuss how the meta-knowledge generated in the activity may be classified and re-used. Higgs and Cottman (Higgs 1998) introduce the idea of deep semantic interoperability, achievable through a Universal Data Access Broker but the scope appears to be towards transaction management rather than complete data integration.

Because of all these anticipated problems, the ANSI Standard Reference Model (X3.138) was developed in the 1980s (Gradwell 1987), emerging in 1993 (ISO 1993) as an associated part of the standard for a framework for Information Resource Dictionary System (IRDS) developed in 1990 and 1993 (ISO 1990). Among early language bindings in IRDS were specifications for Pascal, COBOL, Ada, C and SQL. Language bindings can in principle be defined for any language. Use of the IRDS is yet to be exploited in full. Users are still reluctant to extend the levels beyond standard data dictionaries. The tendency is to design flat systems where the need to cross levels is avoided. Further information on the IRDS objectives has been compiled by Gradwell (Gradwell 1990).

Figure 1: The IRDS in terms of four levels

A basic scheme for the IRDS is shown in Figure 1. The schematic representation of the IRDS Standard (Gradwell 1990, ISO 1990) shows the level-pairs viewed in the direction of reducing abstraction. In the rest of this paper, we examine more closely the IRDS including these four levels and their inter-relations. We then discuss how the four levels of the IRDS can be shown to capture the universal nature of the reference model because it can be demonstrated that these can be constructed formally. When expressed formally the significance of the adjointness with the corresponding increasing abstraction comes to the fore. This will be shown here in the categorial representation but the main attention will be focussed on the direction of reducing abstraction as in the informal IRDS diagram. Technically this is the lower limit of the adjoint pair (Taylor 1999). The full significance of the upper limit, that is the increasing abstraction, will be explored in a subsequent technical report.

2. The Information Resource Dictionary System IRDS

Before embarking on a full formal description of the IRDS, some understanding and informal insight into its interpretation might be useful. The IRDS is constructed on four levels. Each level taken with its adjacent level acts as a level pair so that there are three level pairs across the four levels. This means that each point at each level is directly related to a point at the other level in the level pair.

The top level is the Information Resource Dictionary Definition Schema (IRDDS), in which concepts relating to policy and philosophy are defined. For example, object-oriented abstractions are to be declared at this level. In principle, only one instance of an IRDDS need be defined for a platform. In a coherent system there can be only one collection of such concepts. With the open-ended nature of object-oriented structures, however some extensibility may be required.

The second level is the Information Resource Dictionary Definition (IRDD) in which schema facilities are defined. Each system will have its own IRDD definition. For example a COBOL IRDD would declare that record-types were an aggregation of single- or multi-valued data field-types while one for SQL would declare that table-types were an aggregation of single-valued data fields.

The third level is the Information Resource Dictionary (IRD) which defines the intension for an application, giving names and constraints. There will clearly be many intensions defined in an organization, one for each application. Names, types and other constraints will be given to data objects, network connections, protocol names and signatures and server and client functions.

The fourth level is the Information Resource Data (APP) which gives the extension, the data values. There will be one extension for each intension, the values being consistent with the names and constraints of the intension. Data values may be simple objects as in SQL or complex objects as in computer-aided design and multimedia systems.

One instance of the Information Resource Dictionary System represents one platform, paradigm or model. Take as an example the relational model. Level 1 would be real-world abstractions, level 2 the constructs available, level 3 the data names and level 4 the data values.

Between each level the mappings are strictly defined by their starting and terminating points in the respective levels. In particular it should be noticed that the interpretations of the mappings can only be appreciated by considering both directions for each respective mapping. The bottom-up mappings are described in the formal model. The top-down mappings are as follows:

· Between levels 1 and 2 (IRDDS and IRDD), there is the mapping Policy acting as a level pair. This level pair exists only in IRDS-type systems in which constructive facilities in a system are related to real-world abstractions. For example Policy would indicate how a network-centric capability is made available in a particular approach.

· Between levels 2 and 3 (IRDD and IRD), there is the mapping Org acting as a level pair. This level pair provides a standard data dictionary function of, for instance, saying which classes are available in an object-based system or which servers are available on a network.

· Between levels 3 and 4 (IRD and APP), there is the mapping Data acting as a level pair. This level pair can be thought of as the state of the art of an information system: to link values to names so that data can be addressed by name rather than by physical location.

· Between levels 1 and 4 (IRDDS and APP), there is the mapping Platform acting as a level pair. This level pair short-circuits the navigation through four levels by giving a direct mapping from real-world abstractions to data values. The use of this mapping is described later.

The IRDS standard is the basis for relating heterogeneous systems across platforms, that is systems based on different paradigms. While there is only one instance of the top level (the IRDDS), this level is extensible and new concepts and abstractions can be added as desired. From the point of view of client/servers, the IRDS provides the ability to run an organization with many different paradigms all integrated through the four-level structure. The critical mapping is Platform, that is the arrow from IRDDS to APP, relating concepts to values. By determining this mapping for all types of system, the problems arising in re-engineering are avoided to some extent as all types of approach to information systems can be run in an integrated fashion. The next task is to formalize the diagram in Figure 1 so that a sound scientific basis can be developed for the IRDS model to handle heterogeneous systems.

3. Formalizing the IRDS

Constructive mathematics attempts to develop logically what can work in practice and can therefore provide the necessary universality for interoperability of heterogeneous data systems with consistency and quality assurance in the real-world. Category theory (Barr 1990, MacLane 1998, Poigné 1992) is particularly appropriate for modelling multi-level relationships for it is essentially concerned with links between objects. It has been shown, for instance, to cover adequately dynamic aspects in hypermedia (Heather 1997).

Category theory provides a universal construction for formalizing information systems. It is this uniqueness that provides the universality to form the basis of a general consistent system. An example is now given for a prototype information system focusing on the aspect of a cross-platform system as a heterogeneous distributed database relying on the categorical product construct as a data model (Nelson 1996). In this approach, each class definition can be identified as a collection of arrows (functions) forming a category IRD and each family of object values conforming to a particular class definition as a category APP. The mapping from the intension (class definition) to extension (object values) is made by a functor Data which enforces the various constraints specified in IRD. Category IRD is the intension corresponding to the third level in IRDS and APP is the extension corresponding to the fourth level.

The intension category IRD is a family of categories, representing definitions of classes, associations (relationships) and coproduct structures indicating inheritance hierarchies. The arrows within it may be methods as in object-based systems, network connections between clients and servers, logical connections as in network databases, or functional dependencies as in relational database schemas. It should be emphasised that categorical approaches naturally include procedures and functions through the underlying arrow concept ensuring that both structure and activity can be modelled in a multi-level manner. The category APP is also a family of categories, representing object values and association instances. The functor Data mapping from the intension to the extension not only connects a name to its corresponding set of values but also ensures that constraints specified in the schema, such as functionalities of relationships, membership classes and functional dependencies, all hold in the extension.

It is relatively straight-forward in category theory to extend the intension and extension two-level structures in a universal manner to handle the four levels of IRDS. In categorial terms each of the four levels of IRDS is defined as a category. Between each level there is a higher-order function, a functor, which ensures that certain consistency requirements are met in the mapping between the source and target categories. The abstractions level (top) is a category IRDDS which defines the various abstractions available for modelling real-world data. The next level is a category IRDD defining the various construction facilities available for representing abstractions and data in a particular system. There is therefore, for one instance of IRDDS, many instances of IRDD, one for each type of model such as object-oriented, relational, network and simple record-types as in data processing.

Policy

IRDDS IRDD

Name

APP IRD

Figure 2: IRDS Levels in Functorial Terms

The data functor (level pair) Policy maps target objects and arrows in the category IRDDS to image objects in the category IRDD for each type of system. This mapping provides at the meta-meta level the data for each kind of system, that is to say how each abstraction is to be represented. We also label the functor pair Org relating for each system the constructions in IRDD with the names in a particular application in IRD. Combining these new constructions with the product ones above gives the direct and universal representation of IRDS shown in Figure 2.

The remaining functors MetaMeta, Meta and Name are the duals of Policy, Org and Data respectively. MetaMeta for a given IRDD relates the data modelling facilities provided by a system to the universal collection of abstractions defined in IRDDS. Meta for a given IRD relates the schema definition (intension) to the constructs available in the system defined in IRDD. Meta therefore relates a name in the intension to a modelling concept in IRDD such as a class name to the class construction. Name for a given APP relates a data value to its property name as defined in the intension IRD.

It will be noted that in Figure 2 all the mappings are two-way and that two compositions emerge. In category theory, Figure 2 is a composition of functors with Platform as the overall functor from IRDDS ® APP, such that for each type of information system the following compositions hold:

Platform = Data ° Org ° Policy

Sys = MetaMeta ° Meta ° Name

An obvious benefit is that we can relate concepts across platforms by comparing the functors Platform : IRDDS ® APP for each of our types of system. However, for a full consistency we should consider the two-way mappings and ensure that composition holds in both directions. Such consistency is achieved in category theory by adjointness. The topic of adjunctions, their composition and their relevance to information systems is discussed elsewhere (Rossiter 2000).

3.1 Composition of Adjoints

The IRDS application shown in Figure 2 involves the composition of adjoints, that is an expression is derived in which two or more adjoints are adjacent to each other. It is part of the power of category theory that adjoints can be composed in the same way as other arrows. For example consider the adjoints shown in Figure 3.

A B C D

Figure 3: Composition of Adjoints

Then we may have six adjoints (if the conditions are satisfied):

where Û indicates adjointness.

The advantage in deriving compositions of adjunctions is that we have the ability to represent the mappings in either abstract or detailed form. The overall composition gives a simple representation for conceptual purposes; the individual mappings enable the transformations to be followed in detail at each stage and provide a route for implementation. The uniqueness of the components means that an adjunction can be resolved where there is a component missing.

4. Composed Adjunctions in IRDS

The ability to compose adjoints naturally means that we can combine well together such diverse features as policy, organization and data in a single arrow. Returning to the IRDS representation, we can see the following adjunctions need to be investigated in more detail:

We can construct the 4-tuple to represent the composed adjunctions defined in Figure 2:

where P is the functor Policy, O Org, D Data, A MetaMeta, M Meta and N Name.

If the conditions of this adjunction are met, we can represent the composed adjunction:

Platform Û Sys

by the 4-tuple:

<Platform, Sys, h_irdds, e_app>: IRDDS ® APP

where Platform = DOP, Sys = AMN, h_irdds is the unit of adjunction and e_app is the counit of adjunction.

This adjunction can be evaluated for each application giving a collection of 4-tuples. Comparison of these 4-tuples then gives the mechanism for interoperability between applications both heterogeneous and homogeneous.

5. Example of Adjoints in IRDS: Information Systems based on Different Models

Categories: example objects

IRDDS: Aggregation, Inheritance, Supertype, Subtype, <Subtype, Supertype>, Classification, Association,...;

IRDD: Base_table, Tuple, Inher_table, Class, Tree, Struct, Bag, Set, List, Array, Base_Class, Supertype_Class, Subtype_Class, ,...;

IRD: Student <id, name, address>, Module <title,semester>, Postgrad_student<id, thesis_title>, Student <id, name, address, thesis_title>,...;

APP: StudentO {<1234, James, '15 Montfort Ave'>, <1345, Roberts, '27 Park Road'>, ...}, Postgrad {<1234, 'The Language X'>,...}...; Module {<databases,2>, ...}, StudentR {<1234, James, '15 Montfort Ave','The Language X'>, <1345, Roberts,

'27 Park Road',''>, ...}

Functors

Policy: IRDDS ® IRDD

PolicyR takes:

Aggregation ® Tuple ® Base_Table;

spt: Supertype ® Tuple; sbt: Subtype ® Tuple;

Inheritance ® spt(Supertype) È sbt(subtype) ® Inher_Table

PolicyO takes:

Aggregation ® Struct ® Base_Class;

Inheritance ® <Subtype,Supertype>;

p_r<Subtype,Supertype>®Struct® Supertype_Class;

p_l<Subtype,Supertype> ® Struct ® Subtype_Class

Org: IRDD ® IRD

OrgUniDDR takes:

Base_Table ® Module<title, semester>;

st: Tuple ® Student<id, name, address>;

po: Tuple ® Postgrad<id, thesis_title>;

Inher_Table ® st(Tuple) È po(Tuple) ® StudentR<id, name, address, thesis_title>

OrgUniDDO takes:

Base_Class ® Module<title,semester>

<subtype,supertype> ® <Postgrad, Student>

st: Struct ® Student<id, name, address>;

po: Struct ® Postgrad<id, thesis_title>;

Supertype_Class ® st(Struct);

Subtype_Class ® po(Struct)

Data: IRD ® APP

DataUniDBR takes:

Module<title,semester>®Module{<databases,2>,..}

StudentR<id, name, address, thesis_title>

® StudentR{<1234, James, '15 Montfort Ave','The Language X'>, <1345, Roberts, '27 Park Road',''>,..}

DataUniDBO takes:

Module<title,semester>®Module{<databases,2>,..}

Student<id, name, address> ® StudentO{<1234, James, '15 Montfort Ave'>, <1345, Roberts, '27 Park Road'>, ...}

Postgrad<id, thesis_title> ® Postgrad{<1234, 'The Language X'>,...}

Composed functors

Platform: IRDDS ® APP

PlatformUniR = DataUniDBR ° OrgUniDDR ° PolicyR

PlatformUniO = DataUniDBO ° OrgUniDDO ° PolicyO

PlatformUniR takes:

Aggregation ® Module{<databases,2>,...};

Inheritance ® Student{<1234, James, '15 Montfort Ave','The Language X'>, <1345, Roberts, '27 Park Road',''>,...}

PlatformUniO takes:

Aggregation ® Module{<databases,2>,...};

Inheritance ® p_r<Subtype,Supertype> ® StudentO{<1234, James, '15 Montfort Ave'>, <1345, Roberts, '27 Park Road'>, ...};

Inheritance ® p_l <Subtype,Supertype> ® Postgrad{<1234, 'The Language X'>,...}

Natural Transformation

a_irdds : PlatformUniR ® PlatformUniO

where irdds is an abstraction in IRDDS.

Adjoint

< Platform, Sys, h_irdds, e_app> : IRDDS ® APP

where irdds is an abstraction in IRDDS and app is values for a table or class in APP.

Platform = DOP, Sys = AMN, h_irdds is the unit of adjunction and e_app is the counit of adjunction.

P is the functor Policy, O Org, D Data, A MetaMeta, M Meta and N Name

Figure 4: Example of Adjoint Platform Û Sys for object and relational systems for student data

A simple example is shown in Figure 4 of the adjointness found when a comparison is made of the mapping from the top level IRDDS to data APP for relational and object systems holding similar data definitions for students. The example shows the categories involved IRDDS, IRDD, IRD, APP, the mappings between these categories as the functors Policy, Org and Data, the composition of these functors Platform, the natural transformation comparing the composed functor Platform for two different systems and the composed adjunction Platform Û Sys.

There is one top-level IRDDS as there is one collection of universal abstractions; many functors Policy each one taking the abstractions to a collection of constructs available in a particular approach; many functors Org each one taking the constructs available to the data definitions (schema) in a particular database and many Data each one taking the schema to the data values in a particular database. Org provides data dictionary facilities and Data database facilities. So OrgUniDDR and OrgUniDDO are data dictionaries for the student database in relational and object systems respectively; DataUniDBR and DataUniDBO are the student databases (intension-extension mappings) in relational and object systems respectively.

The comparison in the example is between an SQL-92 relational system and an object-based system. Inheritance is not captured naturally by the SQL-92 system but is represented by the summing of the attributes in the supertype and subtype to give one table-type at the schema and application levels. Inheritance is represented more naturally in the object system with the <subtype,supertype> pair captured in the schema and instances generated in the application for both subtype and supertype when insertion is made at the subtype level.

PlatformUniR shows the mapping from abstraction to data values in a relational system; PlatformUniO shows this mapping in an object system. A comparison of these two mappings is given by the natural transformation a_irdds. This enables the relational and object systems shown to be integrated readily as there is a common entry point to the information systems in the IRDDS category. The adjoint given by the 4-tuple: <Platform, Sys, h_irdds, e_app> defines the two-way mapping between Platform and Sys at an abstract level. The detailed form for a composed adjunction, involving three functors in each direction, provides a basis for machine representation. Implementing these adjunctions will give a rigorous method for relating heterogeneous systems.

6. Implementation

For experimental testing purposes, an example prototype information system was developed called the Categorical Product Data Model (CPDM) which can formalize, for instance, the object-relational model (Rossiter 1994). The purpose of this prototype was to test the theoretical representation and to examine the ease with which such a representation could be implemented on the computer.

A prototype (Nelson 1996) of CPDM was realized using the platform of P/FDM (Gray 1992), an implementation of the functional database model developed at Aberdeen University. Categories and functors were coded so that the two categories IRD and APP could be defined together with the mapping Data between them. In the actual work described in (Nelson 1996) the categories IRD and APP are called INT (for intension) and EXT (for extension) respectively. The universal nature of category theory means that it is a simple matter to extend the product data model CPDM, defined as a two-level structure, to handle the four levels of IRDS. Further work is planned to explore further the details of the management of the four-level architecture for assisting in the control of cross-platform operations.

7. Discussion

A formal universal description, based on the ISO standards for Information Resource Dictionary System (IRDS), has been developed to provide a complete definition of an open information system from the physical data values held to the concepts employed for data and function representation and real-world abstractions. Such a multi-level formalism can be used to control the evolution of information systems by creating an environment where heterogeneous systems can be compared for cross-platform performance. Current trends towards more structured programming techniques and more disciplined software engineering environments can very usefully exploit the IRDS approach. The prototype system developed CPDM also shows that an implementation based on the categorical model is feasible.

The potential which the IRDS possesses, however, will only be realized for consistent cross-level operation if a formal underpinning of the standard is achieved as described in this paper. A categorial IRDS achieves greater power than that envisaged in the original standards. For instance Spurr (Spurr 1990) comments on the difficulties of using the IRDS standard dictionary with CASE tools because of the lack in IRDS of a natural way of modelling object structures. Our work shows the natural correspondence between categorical databases and object structures making possible a complete and faithful representation of the object-oriented paradigm across the four levels (Nelson 1996). Our work also shows that in open representation systems such as dates, the four-level approach always gives ultimate closure.

Our conclusion is that the theory shows that for situations where there are open heterogeneous systems, which have to be coherently designed and implemented, the optimal way forward is the four-level closure path described in this paper.

References

Barr, M., Wells, C. 1990 Category Theory for Computing Science, Prentice-Hall.

Cattell, R. G. G., 2000. The Object Data Standard ODMG3.0, Morgan Kaufmann.

Computer Associates, 2000. Platimum Products and Solutions, http://www.cai.com/products/platinum/products.htm.

Crawley, S., et al, 1997. Meta-meta is better-better!, IFIP WG 6.1 International Working Conference on Distributed Applications and Interoperable Systems, DAIS’97, Cottbus, Germany 12pp.

Duwairi, R., et al, 1996. Schema Integration Meta-Knowledge: Classification and Re-use, 14^th BNCOD, Edinburgh, Springer 1-17.

Gradwell, D., 1987. Developments in Data Dictionary Standard, Computer Bulletin.

Gradwell, D., 1990. The Arrival of IRDS Standards, 8th BNCOD, York, Pitman, pp. 196-209.

Gravano, L., Papakonstantinou, Y., 1998. Mediating and Metasearching on the Internet, Data Engineering, 21(2), pp. 28-36.

Gray, P. M. D., et al, 1992. Object-Oriented Databases: A Semantic Data Model Approach. Prentice Hall.

Heather, M. A., Rossiter, B. N., 1997. Content Self-awareness in Distributed Multimedia Publishing: the Need for a Unifying Theory, in: Third International Workshop on Principles of Document Processing (PODP’96), ed. C Nicholas & D Wood, LNCS, 1293 Springer-Verlag 59-86.

Higgs, M., and Cottman, B., 1998. Solving the Data Interoperability Problem using a Universal Data Access Broker, Data Engineering 21(3) pp. 34-42.

IBM, 1999. IBM’s updated XML Toolkit, http://www.software.ibm.com/ad/features/xmi.html.

ISO, 1990. Information technology - Information Resource Dictionary System (IRDS) framework, Standard ISO/IEC 10027 (1990); 10728 (1993).

ISO, 1993. Information technology - Reference Model of Data Management, Standard ISO/IEC 10032 (1993).

Ivengar, S., 1999. A Universal Repository Architecture using UML and MOF spanning Platforms by addressing Semantic and Object Interoperabilities, Component Strategies, May 1999, 38-52.

Mac Lane, S., 1998. Categories for the Working Mathematician, 2nd ed, Springer-Verlag, New York.

Nelson, D. A.,Rossiter, B. N., 1996. Prototyping a Categorical Database in P/FDM. Proceedings of the Second International Workshop on Advances in Databases and Information Systems (ADBIS’95)}, Moscow, 27-30 June 1995, Springer-Verlag Workshops in Computing, ed. J Eder and L A Kalinichenko, ISBN 3-540- 76014-8, 432-456 (1996).

Poigné, A., 1992. Basic Category Theory, in: Abramsky, S., et al, (ed), Handbook of Logic and Computer Science, I Background: Mathematical Structures, Clarendon Press, Oxford 416-640.

Rossiter, B. N., Nelson, D. A., Heather, M. A., 1994. The Categorical Product Data Model as a Formalism for Object-Relational Databases, Computing Science Technical Report no.505, University of Newcastle upon Tyne.

Rossiter, B. N., Heather, M. A., 2000. Handling Inconsistency with the Universal Reference Model, MS’2000 International Conference on Modelling and Simulation, Las Palmas de Gran Canaria.

Spurr, K., 1990. CASE Tools, Does the ISO Standard IRDS provide Sufficient Support? in: Fourth Generation Systems, ed. S Holloway, Chapman and Hall, Unicom 36-47.

Taylor, P., 1999. Practical Foundations of Mathematics, Cambridge Studies in Advanced Mathematics, Cambridge University Press.

Wiederhold, G., 1992. Mediators in the Architecture of Future Information Systems, IEEE Computer 25 pp. 38-49.