|
|
|
CIDOC Conceptual Reference Model
Introduction to object oriented modelling |
Produced by the ICOM/CIDOC
Documentation Standards Group
Editors: Nick Crofts, Ifigenia Dionissiadou, Pat Reed.
September 1998
Copyright © 1998 ICOM/CIDOC Documentation Standards Group
In March 1996 the CIDOC Documentation Standards Working group decided to adopt Object Oriented modelling techniques for the presentation of the CIDOC Conceptual Reference Model.
This decision was not just the result of a desire to be fashionable but was based on the very real advantages which Object Oriented techniques offer over a more traditional relational approach.
The goal of this introductory document is to explain the basic concepts of object oriented modelling, in terms accessible to the non specialist, in the hope of making the CIDOC Reference Model easier to understand.
As the name indicates, the goal of the CIDOC Reference Model is to provide a reference for cultural and scientific information systems which allows information to be structured in a coherent and consistent way. Ideally, information systems designed in accordance with the Reference Model should, to a large extent, be compatible and able to exchange information easily.
OO modelling is an important contribution towards this objective since it overcomes some of the limitations of traditional relational modelling:
To people with a background in relational modelling, object oriented techniques can sometimes appear confusing and difficult to grasp. The terminology involved is not always immediately clear and explicit and some OO 'gurus' have an annoying habit of exaggerating the differences between the two approaches, sometimes treating relational modelling concepts as being totally incompatible with an OO techniques. Fortunately this is not really the case. Many, if not all of the basic ideas and concepts used in relational modelling turn up again, albeit slightly transformed and viewed from a new angle, in an OO context. Relational 'Entities' are a lot like OO 'classes' and class 'inheritance' turns out to be a lot like entity 'sub typing'. Contrary to what you may have heard, you don't need to 'unlearn' everything you know about data modelling in order to understand what OO modelling is about.
A second point which needs to be made is that modelling techniques, OO or relational, are independent of the technology used to run database applications. An OO model can be implemented in using a relational database management system, just as a relational model can be made to function on an OO database. Some thought may be necessary for the conversion to work properly, but using an OO data model does not commit you to using an OO database system.
Since you are reading this document you are probably unfamiliar with OO modelling terminology. This section attempts to shed some light on the following concepts:
An object is any physical or tangible thing, such as a person or an item in a collection, that can be identified and described. The classification of objects is the heart of the OO approach. This is not to say that other modelling techniques are not concerned with classification, but that OO modelling is primarily concerned with the description and classification of objects.
Naturally, a classification system leads to the creation of classes. Classes are groups of objects which share many of the same characteristics, or attributes. A class is, in effect, defined by the attributes of which it is composed. (As we mentioned earlier, OO classes have a lot in common with relational entities.)
Something which can at first be confusing for people with a background in relational modelling is that class attributes are often qualified by labels which differentiate their relation to the class e.g. has a, consists of, applied by, affected by etc. This sort of labelling only occurs in Entity Relation models as a means of describing relations between entities, the attributes of an entity are not usually characterised in this way.
The attributes by which a class is defined may be simple types such as integers, which are defined by the system, or more complex types which have been defined as part of the OO classification system, that is, other classes. A horse, for example, may be said to have an attribute legs of which the usual value would be 4. This is simply an integer - an elementary notion which requires no further description. However, the horse may also have an attribute owner, which is clearly a person. In an OO system, Person would generally by defined as a object class, having its own attributes.
Relational models sometimes incorporate the idea of sub-typing, whereby a relational entity is subdivided into several more specific entities: an entity describing Documents, for example, may be made up of sub-types Books, Periodicals, Pamphlets, etc. This is generally a fairly ad hoc process in relational modelling and there are no firm rules to define how sub-types are defined. OO Modelling takes this concept one step further by allowing classes to be organised into a class hierarchy. In the example just used, Books, Periodicals and Pamphlets would be defined as specialisations of the class Documents; inversely, Documents would be described as a generalisation or abstraction of the more specialised classes.
An OO class hierarchy is governed by the rules of inheritance. A subclass automatically acquires, or inherits the attributes of the more general class to which it belongs. Thus, if a Document has the attribute Title, all Books, Periodicals and Pamphlets would also automatically have a Title. Subclasses will usually also have attributes of their own: a Book may have an ISBN number, a Periodical will have an Issue number, and so on. Attributes associated with abstract classes are inherited down through the hierarchy so that successive specialisations become progressively more detailed.
The class hierarchy is often referred to as an Isa structure - a book is a document, just as a car is a vehicle. Isa structures often form complex, multi-level hierarchies, starting with extremely abstract and general classes, such as physical objects and animals, and descending through successive levels to highly specific classes such as nitrogenous compounds and nematode worms.
This sort of multi-level hierarchy will be very familiar to anyone who has worked with a standard classification thesaurus such as AAT. An OO model effectively allows the classification hierarchy to be built-in to the data structure.
Of course, the class hierarchy is not the end of the story. Classes on their own are just classification categories into which instances of actual objects can be placed. Instances are, in effect, examples of classes: the Mona Lisa is an instance of the class Painting. A particular instance of a class will usually have values for all its attributes. (In other words, the instances of a class are very much like the records of a relational database.)
At this point it may be useful to look at an example of OO modelling so as to help put some of these concepts in place. Let us suppose we need to model the information that an object was manufactured by a particular person at a particular time and place.
An ER model
Using an ER model we would probably create a Person entity and an Object entity and link them with a relation Creates. Time and Place might also be defined as entities and linked to the relation Creates, or they might simply be treated as attributes of the Creates relation.
This approach works well enough but it has few drawbacks since some semantic information is lost in the modelling process. Attempts to extend the model, or to use it in ways that were not anticipated, will tend to make these shortcomings apparent.
Nothing in the ER model tells us that an act of creation has attributes in common with other intentional acts. If a relation is added to represent acts of destruction,for example, we would have to repeat the same links to time and place. It would be difficult in such a schema to identify all events that took place at a certain time or place without scanning multiple relations.
An OO model
The manufacture of an object is considered as an instance of Creation. Creation results in a Man-made object. The Creation class is a subclass of Method Use. It thereby inherits all the attributes of the super class Events which have time and space attributes, as well as the link to the Method which is applied. The Method use super class is also linked to the class People - the person or group of persons responsible for the act of creation taking place.
In the OO model, a great deal more semantic information has been captured, which helps to make it more flexible and robust. Destructive acts can readily be added to the model as a specialisation of Method_use. They thereby inherit all the attributes of Method_use and Event. Since both acts of creation and destruction are descendants of the class Events, any interrogation which sought to identify events at a certain time and place would automatically retrieve instances of both subclasses.
As we have seen, it is possible to construct quite sophisticated OO models using only the concepts outlined so far. However, OO modelling has a few more wrinkles which can sometimes be extremely useful. These advanced concepts include:
Multiple instanciation is subtly different from multiple inheritance. Sometimes it may be necessary for a particular instance of a class to inherit the attributes of another class without this being generally the case. A picture, for example, might also be a gift. Not all pictures are gifts, but almost anything could be. Multiple inheritance allows a particular painting to be a gift.
Methods are programmes, procedures or algorithms which are embedded in objects. The central idea is that real world objects typically behave in characteristic ways - balls bounce, dogs bark, and employees get fired. Object methods are a means of modelling these characteristics.
The concept of object methods is, in some ways, the most radical idea in the OO methodology since it completely undermines the distinction, treated almost as an article of faith by some computer scientists, between data and processes. However, methods are not yet implemented by all OO database systems. At present no method definition have been incorporated in the CIDOC reference model.
Nicholas Crofts
Co-Chair
Ville de Genève, Direction des Systèmes d'Information
tel: +41 22 418 55 64
fax: +41 22 418 56 01
e-mail: nicholas.crofts@ville-ge.ch
Pat Reed
Co-Chair
Smithsonian Institution, OIT, A&I 2310, MCR 433
tel: +1 202 357 4059
fax: +1 202 786 2687
e-mail: preed@sivm.si.edu