We are converting the old US Epigraphy inscriptions from their TEI
inspired XML format to Epidoc, to the new, P5 conformant Epidoc
schema. At the same time, we are enriching existing and encoding new
inscriptions, all in P5 Epidoc. US Epigraphy had taken a slightly
different approach from some of the more TEI friendly corpora - mainly
it focussed on recording metadata rather than inscription text, and
used a fairly simple fielded approach. This is due to its origins as a
printed catalog of inscriptions in American collections.
A great deal of the existing US Ep. information is going into the TEI
header, specifically the msDesc element. This is what Epidoc is
adopting, and for the most part, it works very well.
However, we are becoming aware of details that don't fit well into
msDesc. I'll note that the US Ep. approach is often to have a
restricted set for many of the fielded values, often borne by an
attribute, and then free text that will allow for more nuanced prose
descriptions, often contained in an element. Again, this works well in
the header, for the most part.
Here is a snippet of the template we are using:
<objectDesc form="xx"> <!-- Put the controlled value for the type of
object in @form -->
<!-- Put the controlled value for the material in @material -->
<!-- not required. Indicates size of inscription. Possible
values are number of lines or number of characters. -->
<!-- This is where to put the dimensions of the stone.
@type should indicate what the dimensions are measuring. We can look
into how this is developed for objects that have more than one
relevant surface or objects that are not square! Also fragmentary. Are
the dimensions of the original object? or just what remains? There can
be more than one dimensions element. @unit can have other enumarated
<dimensions type="surface" unit="cm">
<measure unit="xx" quantity="0"/>
<p></p> <!-- Free text description -->
The first difficulty arises when we try to indicate the type of object
we are describing here. The guidelines indicate that values like
"codex" belong in @form on <objectDesc>. We are looking for a place to
put values like "stele," "sarcophagus," "statue base," "instrumentum,"
"coin" and so on. Additionally, we need a place to put a longer, prose
description of the object that is somehow connected to the attribute.
As things stand now, with @form bearing the information, it seems as
if a <p> should be the first element inside <objectDesc> with more
information about the form. But doing that would disallow all the
structured containers that make the header so useful.
Rather than tying all this information to the whole element,
<objectDesc> it makes more sense to allow it to appear within
<support> and to be indicated using an <object> element, which should
have an attribute that can refer to some other list, so that a
controlled value might be assigned to it.
We have proposed <object> on SF.
The second difficulty arises when we try to indicate the material(s)
of the support. Again, the only place where the value of the material
can be controlled is @material on <supportDesc>, which separates it
from the place where more detailed information can be added, inside
We can use <material> which is allowed inside <support> to indicate
this informaiton. However, <material> doesn't have an attribute that
can refer to some other canonical list (I think they all have @ana,
but that is restricted to an element in the file?).
We have proposed that <material> have an "@ref" on SF.
James suggests that @cref be made global, and replaced on the two
elements on which it appears. having this as a globally availably
attribute isn't a bad idea. It certainly solves this problem.
I don't quite understand the difference between @cref and @ref, but am
willing to learn.
I hope this is clear, and thank you! (just wait until we start to
figure out fakes...)
Brown University Library]