The first thing we need to know is that the creation of a field standard schemata for critical editing is still in development.
The central challenge lies in replacing the visually and ambiguously encoded apparatus criticus with a semantically encoded data base.
This primarily means we need to abstract from the way we eventually expect our apparatus to look. We must think in terms of data types.
What are the different types required to construct an apparatus?
See: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html
The basic form of a TEI apparatus entry is as follows:
Now there are obviously more kinds of variants than a simple form variation.
There are omissions, corrections, additions, etc.
To deal with this variation, we are developing a taxonomy of "types" that you can add to your apparatus entry as follows.
Or
Because we are encoding data types and not presentation forms...
And because our digital representation allows us to transcend the concerns of limited space...
We can add additional data to our apparatus criticus that is simply not possible in printed editions.
It needs to be noted that while we can offer some guidelines about how to semantically encode an apparatus, these guidelines are very much a work in progress.
My goal and the goal of the groups I work with is to help provide guidelines that can standardize this progress as much as possible.
Our work is advanced by partnering with groups who are committed to semantic encoding.
As you encounter new use cases and encoding problems, we can develop an increasingly robust set of guidelines and best practices.
But the point is that this is a partnership, in which we develop together.
This means we will encounter encoding issues to which I cannot give you a direct answer.
But if you can log your encoding issue into our system, we can develop a feature request and work to support this or that data type.
The @type=manual
Note: This is BAD Semantic encoding. It should not be encouraged. But it is a method we can use as we collect information about various use cases. Each @type=manual becomes an instance that alerts us to the need to create an abstract data type.
Feature requests and encoding questions can be asked here: https://github.com/lombardpress/lombardpress-schema/issues. All you need to do is create a new issue and describe your encoding problem. It is ideal if you can add a screen shot of the encoding problem you are facing.
Every time you are tempted to create an @type=manual, you should create an issue asking if there is proper type for the variant instance you are currently dealing with.
The point is that a lot of work is currently on-going. And there is a lot of energy behind it.
If your team commits to this approach, we can leverage your interest and you can have a major voice at the table.
For example, it would be ideal to meet on a yearly basis to develop our encoding standards. Next summer, it would be great to have a representative from the Petrus Hispanus project at each of these standards meetings.
We encode quotations as follows:
We encode references as follows: