‘Dr John Smith’ asked me recently to explain the difference between modules and classes in the TEI.
Modules basically gather together element definitions into a single group. As the TEI P5 Guidelines say:
A module is … simply a convenient way of grouping together a number of associated element declarations. (TEI Modules)
Sometimes, like with the Core module these are grouped together for practical reasons, in most cases, as with the Dictionaries module, this is because the elements are all semantically related to one particular class of text or sort of encoding. An element can only appear in one module.
Each chapter has a corresponding module of elements. In the underlying TEI ODD language, both the prose of that chapter of the Guidelines, and the specifications for all the elements are stored in one file. From this is created both the TEI documentation, and the element definitions used to generate a schema.
The TEI Class system slightly different. While an element can only appear in one module, it can be a member of many classes. While a module is a single unit, classes can contain not only elements (or attributes) but also other classes.
Classes are used to express two distinct kinds of commonality among elements. The elements of a class may share some set of attributes, or they may appear in the same locations in a content model. A class is known as an attribute class if its members share attributes, and as a model class if its members appear in the same locations. In either case, an element is said to inherit properties from any classes of which it is a member. (The TEI Class system)
To enable easier comprehension of the many elements that the TEI Guidelines describe. These elements categorised into classes usually on structural or semantic grounds. The primary division of classes is between attribute classes and model classes. In the first of these, all the elements that are members of the same attribute class share the attributes stored in the definition for that class. For example, the class att.internetMedia contains an attribute @mimeType. There are three members of this attribute class: binaryObject, equiv, and graphic, which means that each of these elements has a @mimeType attribute. Attribute classes may contain other classes, and attributes from a subclass will inherit the attributes from a superclass which contains that subclass.
Elements which are members of model classes are all allowed to appear in the same place. What this means is that in the construction of the content model of an element it will say what content is allowed inside it. In many cases that element will say members of a particular class of elements are able to be used there. One of the benefits of this slight indirection is that if you want a new element you have created to appear in the same places as an existing element, you simply need to add to it that class. For example, the class model.noteLike is used by many elements (and indeed another model class model.global) to allow things which are note-like to be used inside them. The only members of model.noteLike are note and witDetail. So, in any element content model where model.noteLike is referenced, both note and witDetail are able to be used.
You may have noticed that some of the model elements have the suffix ‘Like’ or ‘Part’ in their name. This delineates two types of groupings. If it has ‘Part’ as a suffix, then it is defined by its structural location. For example, members of model.biblPart contains elements which are used inside of the ‘bibl’ element. That is, they are a ‘part’ of that element in the sense of being possibly valid children. However, elements with a ‘Like’ suffix are elements which are of similar semantic nature, and thus able to be used at the same point. For example, model.biblLike contains those elements which are ‘like’ the bibl element in that they contain a bibliographic description of some sort. There are other model classes, such as model.inter which do not contain a ‘Like’ or ‘Part’ suffix, and are convenient groupings of elements (often super classes) that all appear in the same place.
How are modules and classes related? Most classes are defined initially in the TEI Infrastructure module, what attributes or elements are available as part of any TEI schema is dependent upon the modules which are loaded. For example, model.phrase contains many subclasses, one of which is model.lPart (for parts of a metrical line). However, if in generating your schema you’ve not included the Verse module, then the two elements which model.lPart provides, caesura and rhyme, would not appear as an option anywhere you use model.phrase.
Although most classes are defined by the tei infrastructure module, a class cannot be populated unless some other specific module is included in a schema, since element declarations are contained by modules. Classes are not declared ‘top down’, but instead gain their members as a consequence of individual elements’ declaration of their membership. The same class may therefore contain different members, depending on which modules are active. Consequently, the content model of a given element (being expressed in terms of model classes) may differ depending on which modules are active. (Model Classes)
While I hope that clears up some of the confusion, reading The TEI Infrastructure chapter will certainly help, as well as perusing Appendix A: Model Classes, Appendix B: Attribute Classes and Appendix C: Elements for reference and to look at examples. Playing with Roma which allows you to customise your TEI schema (and more) is another option.
.jpg "The Barrow")
