William Kent
Database Technology Department
Hewlett-Packard Laboratories
Palo Alto, California
Oct 1988
> 1 INTRODUCTION . . . 2
> 2 STATICS . . . 2
>> 2.1 Entity Objects . . . 2
>> 2.2 Information Objects . . . 2
>>> 2.2.1 Content . . . 2
>>> 2.2.2 Form . . . 3
>>> 2.2.3 Collectors . . . 3
>> 2.3 Formatted Objects . . . 4
>> 2.4 Sorting Out the Export Concept . . . 5
> 3 CONTAINMENT SEMANTICS . . . 7
> 4 DYNAMICS . . . 8
> 5 NOTES . . . 9
>> 5.1 Miscellany . . . 9
>> 5.2 Efficiency . . . 9
>> 5.3 Import and Update . . . 9
>> 5.4 Illusions . . . 10
This is an attempt to correlate, and perhaps reconcile, several perceptions of what objects are. This is relevant to the Iris work on complex objects, and also to the New Wave notions of presentation and semantic objects.
There may also be some relevance to the Object Server.
We will explore the concepts of formatted object, having both form and content; information object, having content but no real form; and entity object, having neither.
Iris mainly has a semantic model of entity objects at present, although tuples, tables, and scans might be considered rudimentary information objects or formatted objects. This document explores the extension of Iris semantics to embrace such objects.
An entity object is like an Iris atomic object. All it has is an identity, being either a literal or a system-generated surrogate for a non-literal. Object equality is based on these surrogates.
The appropriate metaphor here is to imagine such objects as points occupying no space, embedded in a graph of interconnections constituting the information about these objects. Information is obtained by applying functions, whose effect is to move from some nodes along interconnections to other nodes. Updates add or remove nodes or edges.
This metaphor is just that, and should not be construed as implying anything about implementation or performance. It is a level of encapsulation, or data abstraction, characterizing the kinds of behaviors that define the semantics of the information.
An information object has some notion of content. It might be the name and birthdate of a person, his spouse, and their children. It might be the sequence of front matter, chapters, and back matter in a book. It might be the design specifications of an airplane wing and all of its sub-components.
We can think of an information object as an envelope in the information graph, including one or more entity objects and the functional connections among them. Envelopes can overlap; the connection between a book and its author may occur in envelopes of information about the book and about the author.
Much of the time we will think of an information object as containing information directly or indirectly about one particular entity object, the subject of the information object. Thus we had an envelope of information about a given book, and another about a given author.
Different envelopes might be drawn around the same subject, yielding multiple views. Thus the personnel file on an employee might be a different envelope from his medical history.
The information contained in an information object can be defined by a content specification, much like an Iris derived function with one argument. An information object is obtained by applying a content-spec to an entity object:
info-object = content-spec(entity-object).
Multiple views are obtained by applying different content-specs to the same subject. An information object is thus characterized (identified? described? specified?) by the combination of a content-spec and its subject entity.
We have the rudiments of content specifications in Iris now, as derived functions. We need to extend this with the ability to specify an unnormalized result object, as recursive combinations of lists and bags of objects.
As formulated here, the notion of directly updating an information object may not be appropriate. Instead, the process should be viewed (semantically) as updating the underlying information graph, and then recomputing the information object by re-applying the content-spec. But we will undoubtedly want to implement something more efficient.
It is important in this case not to confuse the object-id of the information object with the object-id of its subject. E.g., the personnel-view of an employee is not the same object as the employee itself; maybe the former is a folder, a different thing from an employee. Similarly, operations on an information object are different from operations on its subject. Deleting a folder does not delete the employee. It does not make sense to refer to the folder's spouse, but to the spouse of the subject of the folder.
On the other hand, there probably are cases where there is only one view, and the information object should be considered the same as its subject.
The notion of semantic object (or database view) corresponds ambiguously to one of the following:
Information objects only have an abstract, semantic notion of form, just enough to provide access to their contents. They don't have any behavior associatable with "real" space, regarding physical sizes, pointer mechanisms, locations, bit sequences (data types), etc. They can be thought of essentially as ordered or unordered lists, whose elements might in turn be ordered or unordered lists, and so on.
We can't associate them with any definite space, or even assume that they are physically disjoint from one another.
We make a subtle but important distinction between two kinds of information objects: those whose contents define their identity, and those whose contents may vary. The former is exemplified by the sentence "John loves Mary", while the latter is exemplified by the concept of the opening sentence of a certain novel. If we say that the opening sentences of two novels are the same sentence, we are using both notions. There is only one sentence "John loves Mary", just as there is only one number 3, even though it may be written many times. If we change the opening sentence of a novel, it is still the opening sentence of the novel, but it is no longer "John loves Mary".
Similarly, we might have two folders containing the same sequence of documents. They are not the same folder, even though their contents are identical. If we remove a document from one folder, it is still the same folder, but the content is different. Thus the sequence of documents is different from the folder that contains it.
The kind of object whose content defines its identity is a "construct", and the other kind is a "collector". The content of a collector is a construct.
In general, a document is a collector, having some sequence of things (or just a big character string) as its content.
We can minimize the distinction in many contexts, by letting most functions on a collector apply to its content. Thus, asking for the third document in a folder can be interpreted as a request for the third in the list of documents contained in the folder. The difference mainly shows up in questions of equality. Two distinct folders are always distinct; if we want to know about their contents, we must compare their contents. A similar distinction shows up with regard to types: the type of a folder is "folder", while the type of its content might be "list of documents".
(Strictly speaking, a collector is an entity object.)
(These categories are not disjoint: literals are entity (atomic) information objects.)
(Will we always consider an information object to be characterized by a subject and a content specification?)
A formatted object has both content and form. It is capable of existing in a user space, subject to operations unknown to the object manager. It has a "format" concept. The formatted object might be stored by the object manager, or it might be materialized as needed.
A format specification, like a content specification, is a function. It might be a formalization and extension of the Iris handle utilities. A formatted object is obtained by applying a format-spec to an information object:
formatted-object = format-spec(info-object).
The notion of presentation object corresponds ambiguously to one of the following:
The overall concept is to apply a format specification to the result of applying a content specification to an entity object:
formatted-object = format_spec(content_spec(entity object)).
In general, a format spec could be applied to any information object that satisfied the argument structure of the format spec.
Format specifications call for more innovation in Iris. We need some notion of interface functions (export functions) whose arguments would be complex Iris structures and whose results are constructs in the user domain, not Iris objects. We probably already have the rudiments of these in such things as handle utilities. We have to promote such things to some kind of first-class status, not just hidden as implementation hacks.
We also need richer storage structures, beyond normalized relations.
We observe that any implementation is storing and maintaining formatted objects. Relational storage is just one particular flavor.
The difference between information objects and formatted objects may be nothing more than the degree of encapsulation, in terms of the kinds of functions that can be applied to them. How do we characterize the difference in terms of programming structures, bit-string operations, pointer manipulation, length dependencies, etc.?
We could consider calling these objects "spatial", or "dimensional", to emphasize the sense of their existing in some real space.
Should also mention the assumption that such objects occupy disjoint pieces of real space. Any apparent overlap tends to be dealt with by copy management.
The notion of being a formatted object is partly associated with the notion of "exporting" an object into a user's sphere of control.
It turns out that we might have several notions, and we have to get our terminology coordinated. Which of these paths is/are considered "export"? Are there different notions, or degrees, of formatting involved here?
CLIENT WS CLIENT WS ------------------------------ ------------------------ | Client space | | Client space | | | | | | 4 | | | | ^ | | | | : | | | Z|----------------------:-----| Z|----------------------| | : | | | | 3 : ................................ | | Iris outer ^ : ^ | | Iris outer : | | space : : : | | space : | --------------------:--:--:--- --------------------:--- : : : : : : : : IRIS WS : : : IRIS WS : --------------------:--:--:--- --------------------:--- | : : : | | : | | 1 2 : : : | | : | | ^ ^ : : : | | : | | : : : : : | | : | | Iris inner : : : : : | | Iris inner : | | space : : : : : | | space : | --------------:--:--:--:--:--- --------------------:--- : : : : : : : : : : : : DATA STORE : : : : : DATA STORE : --------------:--:--:--:--:--- --------------------:--- | : : : : : | | : | | ^ ^ ^ ^ ^ | | V | | 1 2 3 4 5 | | 5 | | | | | ----------------------------- ------------------------
Path 1 represents system caches for system or user data on the Iris server.
Path 2 represents user-specific caches on the Iris server.
Path 3 represents user-specific caches on the client workstation.
Path 4 is what I have meant by "export", where the data is actually passed into the user's control.
Path 5 is Iris-managed data interchange.
We have different notions of "external formats" involved here.
For the caches in cases 1-3 the format is external to the data store, but it is not external to Iris. An application tuner might be concerned with these formats, but not an application definer or user. Much the same applies to the data interchange in case 5; Iris might be at liberty to modify these formats unilaterally, unless affected by some data interchange standards.
In case 4, the external formats are committed to the client, usually arrived at by some sort of negotiation. It is not uncommon for this format to be dictated by the client, and the "export" process is committed to satisfying that format.
So, which of these cases are we going to call "export", using "external formats"? What terminology shall we use for the other cases?
Can we say that formatted objects are only relevant to a client in case 4? And that the occurrence of formatted objects in other cases might be the concern of an "application tuner"?
Also, we might need to be still more careful as to how we distinguish cases 3 and 4. The real difference depends on who controls the operations that may be performed on the data, and also who controls the format specification. The difference might not be based on who owns the space; i.e., the cache of case 3 might use space allocated by the client.
Containment semantics are often implicitly embedded in the formatted object concept. Formatted objects are typically perceived of as discrete, disjoint chunks of storage. Under that metaphor, it makes sense to "delete the whole thing", or to "lock the whole thing".
We need to identify the corresponding semantic concepts relative to the information graph, transparent to how the information might be aggregated or represented.
Relevant behaviors include:
Much of containment semantics pertains to behaviors along connections among objects. We have to define not only what the behavior is, but along what connections it propagates.
For example, deletion of a containing object suggests deletion of a contained object. How do we identify the contained objects, as distinguished from objects related via other functions? And recursively down through the containment chain? And might an object be contained in more than one container, so that it should only be deleted when the last container is gone?
A simple approach is to have exactly one "contains" relationship, along which all behaviors flow. But:
Solution seems to be along the line of function categories (in effect, coloring the schema; is Jurgen developing such work?). E.g., we define categories corresponding to such behaviors as cascading deletion, inheritance, storage clustering, etc., and then assign functions to one or more such categories.
(Develop the unifying role of functions, and how they integrate properties, relationships, messages, procedures, methods, etc.)
There seems to be a dual to the spatial metaphor: formatted and information objects are characterized more by what they contain, while entity objects are characterized more by what you can do with them, i.e., how one can navigate in the information graph.
The procedurality is "in" the database; is it necessarily "in" the objects? Can we really distinguish between:
Mention the problem of multiple arguments (messages concerning multiple objects).
When do these classifications break down? Does an information object always have an entity object as its subject? If there is only one view, can the information object be the same as the entity object? Can we have a formatted object that does not have a related information object or entity object?
In the other direction, we could provide the sense of an entity object having associated information and formatted objects by having default content and format specs defined for the entity type. Or we could consider the context notion again.
An object seems to become a formatted object when it is linearized, or mapped into a two-dimensional space. Is there possibly a continuum, depending on the allowable operations, i.e., the encapsulation?
Where do literals fit into the picture? Long fields are especially interesting, since they start to overlap some of the behaviors and problems of information objects and formatted objects, yet they are atomic objects.
When does granularity become significant?
Explore the notions of relations, tuples, and scans in their current roles as information or formatted objects. When we provide more varied storage formats, will we be storing formatted objects?
We need ordered lists! Otherwise it is hard to define a book as a sequence of front items, chapters, and back items. Explore more carefully how we might apply a function to a whole book, such as print, display, copy, wordcount, etc.
When does some form of self-description need to be embedded in the formatted object? When does it suffice to know the content-spec and format-spec?
Discuss the need to be able to specify formatted objects in the data store and caches. Can these be the primary copies, supporting all queries? Discuss copy management. Are there other related performance specs, e.g., clustering hints? Relate to Jurgen's work, and also to the object server.
Potential tradeoff: efficient structures at the expense of generalized queries. We might not be able to answer inverse queries. And we might not be able to do update (maybe foreign functions can).
Import? Update? Queries and updates on the internals of information or formatted objects? Copy management?
The problem: if an object has been exported, how can the object manager capture updates to the exported object? Possibilities:
Could import blobs, with no "internal" semantics. They are just bit strings to us. (But suppose they have embedded oid's; do we have to be aware?)
Could import blobs, using foreign functions to extract any internal semantics.
Could define some mappings for unpacking blobs (structure blasting?).
What parameters are needed to make import possible? How does the importer understand the content and format specifications under which the export occurred? "Protocols" might consist of functions known at both ends, such that only the function name needs to be passed.
The oid problem.
Still have a potential snafu regarding formatted objects and handles. When stored by the object manager, they behave as though they had prefixes, in order to know what kind of objects they are; on export, the prefixes are stripped.
An object doesn't really exist anywhere. To get very precise, all we have is references to objects, and the question is whether two references are to the same object.
The illusion of coherence...
The user may imagine that he is dealing with a formatted object, but his actions are just navigating through the information graph. Or he might have the benefit of a graphical interface creating the image (illusion) of a formatted object, leading him to imagine that such objects are in the database.
Irony: user interfaces are moving toward the visual metaphor, while I am trying to move the semantics away from it. Why? Encapsulation?
We can often get by with just the illusion of molecularity. If a user asks us for the i-th element of an array, we could follow a GetElement(array,index) function from an atomic array object to the resulting element object, even though the user may think he is specifying an offset "into" the "contents" of the array. We can't get away with that if the user is indexing into the array himself.
The distinction depends largely on who is interpreting the operations on the object. If we are, we can fake the behavior, but if someone else is, then we have to give them whatever structure they need for their operations.
Essential behaviors of real (non-illusory) molecularity are associated with:
This should be expressible in terms of encapsulation. Operations that are unaware of internal structure, and do not invoke structure accessing functions (e.g., accessing relations), may only have illusions of coherence.
The illusion goes pretty deep. In an environment of virtual memory and sophisticated device drivers, there are very few objects that actually occupy contiguous bits on media.