It’s not easy in P5 ...

• P5 has too much prescriptiveness.
  • “Why can’t I/we?” feature requests are common.
  • <rs> should contain <q> and <quote> (closed #1531)
  • Why can’t we use <row> and <cell> within <rdg> and <lem>? (#2000)
• P5 has too many ways of doing (much) the same thing.
  • <name type="person"> vs. <persName>
  • <ref> and <ptr>
  • @ref, @corresp, @key
  • Where do you put your <standOff>?
  • Genetic editing (<surface> and <zone>) , vs. semantic structures (<text> and <div>).
• Is P5 confusing for beginners—or even for experienced developers?
  • TEI allows scholars to encode what they need ...
  • ... but only if they're able to produce valid TEI schema conformance.

The Abstract Model is not abstract enough

A document is said to conform to the TEI Abstract Model if features for which an encoding is proposed by the TEI Guidelines are encoded within it using the markup and other syntactic properties defined by means of a valid TEI-conformant schema. Hence, even though the names of elements or attributes may vary, a TEI-conformant document must respect the TEI Semantic Model, and be valid with respect to a TEI-conformant Schema. Although it may be possible to transform a document which follows the TEI Abstract Model into a TEI-conformant document, such a document is not itself conformant.

As noted above, the notion of semantic conformance cannot be completely enforced in a formal way. The TEI conceptual model is expressed by means of formal specification in a customization file, by means of descriptive prose in the body of these Guidelines, and implicitly by examples of usage. Any inconsistency between, for example, the text of these Guidelines and a part of a specification should be considered an error and reported to the TEI Council for correction. –source: USE chapter, TEI P5 Guidelines

• The Semantic Model isn't really abstract, when it relies on schema definitions, descriptive prose, as well as examples of usage.

Context-dependent content models need workaround

• P5 cannot directly express context-dependent content models.
• <p> in fileDesc/sourceDesc vs. <p> in body/div require different content models
• Current workaround: Use <altIdent> to define two different patterns. (It's difficult for most of us to know how to do that! And it should be trivially easy.)

When content models influence encoding choices

• Do we choose <ab> vs. <p> because one of these is allowed to self-nest and the other is not permitted to do so?
• Modeling limitations should not force encoders to choose markup for structural rather than semantic reasons.

Model classes and attribute classes are confusing

• P5 class system introduces confusions over what belongs where, and why it belongs there.
• We have 86 different attribute classes and 127 model classes as of Guidelines release 4.12.0. (Shouldn’t we have enough now? – but requests for rethinking and reshuffling continue to come in.)
• How did att.global.rendition get this way? Why do we need three attributes for describing rendering in the source text?
• The modular organization of classes, macros, and datatypes is inconsistent (#1710).

Over time, problems accumulate

• Council had been established in 2002 to help create and launch P5 (2007), and thereafter to maintain and update it.
• Consistency in updates was difficult / impossible over time.
• It becomes difficult to introduce requested features without tripping over problems with conformance constraints.
• Stylesheets and infrastructure to maintain P5 is complicated in a brittle way to try to introduce to new Council members.
• We need a more robust system.

What we want for P6

• We need context-dependent content models.
• Constraints need to be meaningful, not applied to reconcile or compromise for validity.
• We will still encode in XML, but TEI should also be readily expressible in other formats (e.g. graph models).
• TEI concepts come first – users should be able to:
  • Know how to do something (how do I?)
  • Adjust it to their research needs (why can’t I?)
  • Express concepts as elements, attributes, or non-XML constructs as needed.

But P5 is not all bad! What aspects of P5 should continue in P6?

• The TEI header
  • Highly expressive modeling of document metadata for which TEI is widely known / heralded
  • Problematic: Extremely and perhaps excessively prescriptive.
  • Nevertheless, an excellent place for standardizing data exchange.
• Capacity to prepare many kinds of output data from the same ground source TEI document.
• Encoding in XML and tree structure for ease of processing
  • e.g., standOff data structures together with trees for preparing editions and data
• Multiple encoding methods => can help to select an encoding strategy appropriate for your project.

Wisdom accrued from P5

• P5 has too many ways of doing (much) the same thing., but it is not only the thing that has to be done, but also the way it is done that needs to be appropriate.
  • e.g., nested/treelike approaches vs. standoff markup/pointer based vs. milestones.
• The TEI vocabulary works like a lingua franca for digital scholarly editions (and other fields) and needs to be retained.
  • e.g., when we talk about <pb>, every other edition nerd understands we are talking about page-beginning.

How will P6 be different from P5?

• The abstract model should focus on concepts and their relationships over content models and serialization.
• Simplify: Reduce redundancies and points of confusion.
• Prioritize scholarly decision-making process for determining how to mark up texts.
• Make it easier to adapt core concepts, with more expressive possibilities in modeling.

A possible path for P6

Abstract Model: Concepts and Classes

• P6 should define and describe textual phenomena, starting from current P5 coverage.
• P6 should organize concepts in a class system

Possible inspiration: schema.org

A possible path for P6

About Blueprints ...

• Blueprints instantiate the abstract model into multiple concrete representations for specific use cases and serialization targets.
• TEI Council would maintain a number of official blueprints.
• Communities of practice and large projects can define and share their own blueprints and co-exist with Council ones.
• Further customizations can be applied to blueprints to adapt them to specific project needs.

What would P6 and its infrastructure look like?

• P6 Guidelines should centrally provide interactive support for blueprint processes.
• A registry of blueprints should be established in a repository, akin to a package manager (PyPI, npm, etc.)

Is this P6 worth the trouble?

• Not worth building P6 if it replicates the same kinds of problems.
• P5 can continue to develop (including adding new features) while P6 is being designed.
  • TEI P5 : TEI P6 :: Python 2 : Python 3
• Down the road, a frozen-in-time P5 could become a stable Blueprint of P6 if our concept (abstract+multiple blueprints) proves viable.
• P6 must be easier to maintain: Needs modifications to the infrastructure.
• P6 work changes the role of our Technical Council in splitting our work for a while.
• If P6 is to develop, it needs support for dedicated meetings, consultation with experts.

Experiments

Council members have spent some independent time experimenting with ideas for P6, but ...

• We don’t yet agree on how to move forward.
• We feel the need to check in with the community before spending more time and resources.
• Thanks for being here at this session! 👋