Object Typification

The object space can have no typification theoretically. But how to understand that two objects describe the same entity, for instance, people, in this case? Since every object has properties, we can try to extract an entity from the fact of presence of some typical properties, for example, for the entity "Person", the properties could be "Name" and "Age". But stars have names and ages too, which does not mean that stars are people. Therefore properties are not reliable for this.

There is only method to resolve the problem of associating objects to entities: we should introduce object typification. Every object in this case should be related to some type which should unambiguously determine the appropriate entity of the real world. For instance, objects of the type "Person" are not starts, but are people, and vice versa. Object typification defines the way of interpretation for all objects of some type. For example, the task of analysis of social bounds has sense for people, and the task of distance analysis has sense for stars, but not vice versa.

So, to understand entities related to objects, we should define a type for every object existing in our space. But it is not enough. Correct interpretation of an object means correct interpretation of its properties, which requires that the same property should be equally named for all objects of the same type. Therefore, every type description should contain the structure of typical object of the type. Only in this case all objects of one type may be processed in common way, reasoning from commonness of their structure.

How should we store object types in the object space to access them efficiently, not less efficient than for objects themselves? The solution is simple: we should represent object types as a special kind of objects. Object types, being objects simultaneously, relate to the special type corresponding to the entity "Type". Such recursive type definition let process them as any other object.

What if an entity is a particular case of some other entity, for instance, the entity "Sportsman" is a particular case of the entity "Person": what type should be defined for the particular entity in this case? The problem is that we can not relate one object to two types simultaneously, but any object of the type "Sportsman" should be related to the type "Person", what can we do? To resolve the contradiction the concept of type inheritance should be introduced.

Inheritance of some derived type from some base type means that every object of the derived type is also an object of the base type by definition, and so it has all the properties of the base type. In our example, we should introduce inheritance of the type "Sportsman" from the type "Person". When inheriting, there is no necessity to repeat the structure of the base type within its derived types: inheritance of properties is implied. Therefore, in spite of the fact that the type "Sportsman" has only additional properties, like a sport kind and achievements, every object of the type "Sportsman" also has all properties of the type "Person", like a name and age.

So to find out is an object related to some type, it is insufficient to get the object's own type: all ascendants of the object's own type should be analyzed too. If the ascendant type set contains the requested type or the requested type is equal to the object's own type, then the object is considered to be related to this type regardless of its own type can be not the same. In our example, according to this rule, every object of the type "Sportsman" is an object of the type "Person" inevitably.

May the object space contain several types for the same entity? Yes, it is possible if types are developed by different companies with no coordination. In this case, objects being of the same entity but of different types will be interpreted differently. The object space, being integrated physically, starts splitting on parts unconnected one with another logically.

There are two solutions for the problem: organizational and technical. The organizational solution includes preliminary standardization of types by some standardization institution. As a result, different companies use the same set of types initially. This approach saves resources for applied system development dramatically, but it is not always possible since standard development requires noticeable amount of time and coordination among many interested parties. So, standards are created, as a rule, after several alternative solutions enter the market.

The technical solution may be applied even after system creation, but it is much more complicated. According to this approach, a standard or a private treaty among companies is created on basis of existing scattered types. The standard defines a new set of standard types covering the appropriate application domain in full. This organizational step is inevitable if we wish to get complete system integration.

Further, every system using its own types should inherit the types from standard ones; a module backing the inheritance should be added. This task does not require modifying a system itself, it can be solved on the level of the service integrating the system to the object space by providing access to objects of the system. As a result, every special system uses its own types to manage its objects, but it is also possible to use the objects out of the system with standard types. It allows us decouple next integration steps for different systems.

The third step is the most complicated one: a new version, based on standard types only, is to be created for every system. Of course, there is an alternative: to convert external objects of standard types to internal types of the system (using ETL or "on the fly"). But this solution has limited scalability, timeliness, and efficiency since the quantity of objects to convert may grow uncontrollably. Efficiency of the system may degrade completely in time, and administration of the converting process may become overly expensive. This approach, of course, can be used in some special cases, when, for instance, the system is not expected to evolve, but it's more long-sighted and scalable to issue a new version of the system.

At the end of the third step, after we have used standard types, we should find objects which instances were multiplied in different systems, reduce the instances to one for every object by removing surplus ones, and replace references to surplus instances by references to chosen master instances. As a result, we restore integrity of the object space: every object is represented with one instance of a standard type, and objects are interpreted in the same way in all systems.

Here the question arises: could such integration result in reducing efficiency of existing systems because we start using remote objects? On the one hand, of course, yes: integration requires some additional resources, it is inevitable. On the other hand, efficiency problems may be resolved after, for instance, a local service caching often used objects may be installed. As a result, somewhat reduction of remote object access efficiency becomes apparent only in case of active modifications of the objects by the remote side.

It is evident that the approach described above is allied to approaches of object-oriented programming, conceptual schema design, relational schema integration, ontology design and fusion, but we can not affirm that it is one of them. The approach absorbed all that is necessary for qualitative system integration within one integrated object space.