Saturday, 14:00

Saturday, 2006-10-28, 14:00
Inside the TEI: Updates, Elections, Business Meeting

(Burnard)
This year:

• schema doc and generation: extensive dev of Roma, internationalization project, tagset now stable and tested outside TEI
• feature structures: ISO 24610/1 now published; work on /2 starting (feature structure declarations)
• structure chapter completely revised
• new draft section of “personography”
• overlap: related concepts discussed in several parts of Guidelines (SA, AI, NH); several sections redrafted (ongoing)
• dictionaries and terminologies: new draft for DI in place but work is outstanding
• relation of header to other metadata standards: revised version of SH in place

In May, Council agreed on preconditions for P5 1.0:

• essential = thorough chapter review, sourceforge.net feature request review, conformance and modification principles defined —no new material; errors remain but it’s complete as a tech spec
• desirable = new material on physical bibliography, expansion of personography, inclusion of agreed feature requests
• nice = dev of usability and migration tools

See also Council minutes on TEI site.
Council also agreed on some compatibility principles for P5 itself amongst different versions—changes shouldn’t break things.

Three focuses: understanding the class struggle, personography + beyond, conformance issues

Why does a user of TEI need to understand the class system? The TEI is more than a collection of elements: it provides a framework for the definition of multiple schemas. Need to be able to say what TEI is relative to other things.
Each element is a member of 1+ classes. One can change a module rather than a particular element.
Elements are also (independent of module) classified structurally and semantically. Attribute classes exist as well; attribute values may be constrained to be a certain datatype.
No more bases, toppings, etc. (pizza chef)—four key modules: tei, textstructure, header, core; otherwise, modules are alike, effectively.

[notes thin here for awhile because this overview isn’t news to me]

The existence of classes lets one say, inter alia, that “new element x is permitted wherever an a (or b or c) is”—as well as the obvious “any of a or b is permitted” or “none of a or b is permitted”

For personography: new model classes model.persTrait, model.persState, model.persEvent —part of names and dates module
This goes beyond the text to structure certain kinds of abstract information related to it (as response to community need). Possible future support might include place-names and gazetteers.

The I in TEI also stands for “interchange,” which depends on interoperability. At what point is something TEI-conformant (or not)? The Conformance specs should allow a user to position their usage as a TEI subset, a TEI customization, or neither.
Once you introduce material from another namespace, you’re in the “neither” group, really.

TEI-Libraries: Perry Treuler will be compiling an ODD of practices at California, Michigan, and Virginia
Memo of agreement with ISO on feature structures: their copyrt statement pertains but TEI are allowed to distribute it the way other materials are.

[then, I think, I tired of note-taking.]

(Rahtz)
Overview of i18n project—494 elements, 116 classes, 476 attributes [missed the element and attribute class-tallies]; within a year, should be able to deliver fr, sp, de, cn, jp of those.
Roma has changed to handle this as well as to offer some canned suggestions.

SIG Reports
?Hopkins, Presentation: purview = tools for presentation and output as well as development; reviewed last year’s tasks, and want to update the TEIWiki with tool mini-reviewsSchreibman, Training: renamed group to Education, to reflect goals better (more than workshops!); encourage people to post to TEIWiki about courses they teach and examples they’d like to share; begin gathering links to documentation and best practices

Eide, Ontologies: discussed problems of authority control (x in TEI = y in another system), and points of access in TEI docs where other things can interface; someone from the Perseus project (?) will work on FRBR integration

Bauman (for Bruvik), Overlap: discussed some problems + how to deal with extended examples re: i18n