Facsimile zone types

[TomazErjavec]

Some time ago we introduced a closed set of types for zone. After some discussion in #94 these types should be revisited and improved. Problems with the current value set are (at least):

• We introduce PressMint idiosycratic types but several partners will take ALTO as their source format, and ALTO already has defined page types. In particular, ALTO documentation specifies that "Each page is divided into different areas (TopMargin, LeftMargin, RightMargin, BottomMargin and PrintSpace). The margins may contain text or other objects that are not part of the main body.", while we have (only) "pageBody" as a page-level type.
• Several types refer to the semantics of the content rather than to facsimile-specific distinctions (heading, advertisement, illustration, table); I now think this is wrong, such types should be associated with the transcription, i.e.placed on div or gap.
• We also have linguistic distinctions among type values (word, token). This is again problematic as we are making linguistic distinctions in the facimile and also leads to problems as a token/word can be split in two lines or even pages, so one word would be in two zones, and the two zones are not in fact a "word". Furthermore, OCR can use different tokenisation than is present in the transcription.

With these comments, I would propose to have a different range of types for zone, which would:

• as far as possible be based on ALTO (use their exsiting page types, except for capitalisation, where I would - maybe? - keep TEI camel-case)
• encode only types that an OCR engine could determine, not the semantics of the underyling text

My proposal:

• printSpace: same definition as our current textBody, i.e. "a zone encompasing the page text, i.e. the page without the header, page numbers, footer etc."
• margin, topMargin, leftMargin, rightMargin, bottomMargin: these are, except the first, taken from ALTO, the first is there to generalise over the particular margins
• block: the same as the value we have now, except that our definition has "a block (i.e. a rectangle) of text" and I would leave out that it has to be a rectangle, as otherwise we need another value for polygons - then again a "block" in not a polygon so it might still make sense to have a distinct value for general polygons, or, alternativelly, rename "block" to something more general?
• column, line: unchanged, although, admiteddly, this is making some semantic distinction, still, I think, in the scope of OCR
• seg or segment: same as block, except for small rectangles/polygons, i.e. those containing a word, part of a word or even a character

Once we reach a consensus on this I would change the ODD accordingly - in the meantime, comments welcome!