Object types

What are good examples of object types?

Any of the following:

• Word
• Morpheme
• Phoneme
• Grapheme
• Phrase
• Clause
• Sentence
• Paragraph
• Episode
• Speaker_turn
• Book
• Chapter
• Verse
• Page
• Line

In short, anything that arises as a set of textual units of some sort with similar characteristics is a good candidate for being grouped into an object type.

This is because the units, if they have sufficiently similar characteristics to be a group, will benefit from having specific characteristics that are shared by all the similar units (i.e., features).

Can object types form hierarchies?

Yes and no.

No because there is no "inheritance" relationship between object types in EMdF. Thus you cannot use the concept of "super object type" or "parent object type" in constructing an object type, as would be the case in an Object Oriented programming language.

But this kind of inheritance is not the only kind of inheritance. There is a kind of inheritance which Emdros does support, and it has to do with how objects of different object types nest inside each other, as Phrases within Clauses, for example. Or Chapters within Books. So, can object types form these kinds of hierarchies?

Yes and no.

Yes because you, as the database designer, may be able to determine that objects of a certain object types will always be built from objects of a lower object type.

No because Emdros does not provide a way of making these "buildable_from" relationships explicit. They must be implicit in the monads of the objects themselves.

But yes, you can, as the Emdros application designer, choose to always create objects in such a way that the object types form a hierarchy.

Can you have multiple hierarchies?

Yes, in the same sense as you can have single hierarchies: Implicitly in the monads of the objects. The multiple hierarchies can represent different perspectives on the same database.

For example, there may be one hierarchy, "Book > Chapter > Paragraph > Sentence > Word", and another hierarchy, "Book > Page > Line". It is easy to see that objects of the "Line" object type need not be embedded inside any "Sentence" objects. In fact, they will often overlap.

How do I decide which object types I should have?

That is a design question which cannot be answered in general, since it depends on the use to which you hope to put the database. But here are some ideas:

• Find out what the textual units are.
• Can you group the textual units into groups with similar characteristics? If so, make object types out of the groups.
• Try to identify unit hierarchies. They will often help you think clearly about the units and their groupings.
• Decide on a "lowest object type" that is at the bottom of most of the hierarchies. This is often "Word", but can also be "Grapheme", "Morpheme", "Phoneme", or other units.
• It is, however, not a necessity to have a single lowest unit, and in fact you can have any number of object types that make out the "lowest" levels of the hierarchies.

Help! I need meta-data!

Ah, a common problem. You need to be able to store data about the text, or data that is not textual, or data that is separate from the text. How do you do that?

There are two cases:

1. Data about the text: Create an object type, say "Text" that holds the data about the text. Give this object type the features you need to express the data about the text. Then create large objects that span the monads of each text. Then assign the data to the features of these objects.

2. Non-textual data: Well, if your data is truly non-textual, then just create object types to hold the kinds of data you need to store, then create objects with arbitrary monads that you make up.

What are some examples of non-textual meta-data?

For example, say need to store a sequence of meta-data about hierarchy levels in your linguistic application. You can then create an object type called "HierarchyLevel" with the features you need for each hierarchy level, then create objects anywhere in the monad stream that describe the hierarchy levels in your application. You can put them at the monads {1}, {2}, {3}, etc., or you can put them anywhere else in the monad stream. So long as you will never do a topographic query for both "HierarchyLevel" and real textual data at the same time, the monads can be shared.

Or say you need to store a set of labels. You create two object types: "LabelSet" and "Label", each with a string feature telling use what the name of the label set or label is.

// Create objects with any monadset, e.g., {1}
// The monad sets must, however, be unique and non-overlapping
// for each distinct label set.
CREATE OBJECT TYPE
[LabelSet
  set_name : STRING;
]
GO

// Objects of this type will have the same monad set as the
// corresponding LabelSet object.
CREATE OBJECT TYPE
[Label
  label_name : STRING;
]
GO

Then you create one LabelSet object at any monad (say, {1}), and then create the Label objects at the same monad. In that way, you can get all label sets like this:

SELECT ALL OBJECTS
WHERE
[LabelSet
  [Label]
]
GO