Print

Print


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 -->
       <supportDesc material="xx">

          <support>
              <p></p>
          </support>

          <!-- not required. Indicates size of inscription. Possible  
values are number of lines or number of characters. -->
          <extent>
             <!-- 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  
values. -->
               <dimensions type="surface" unit="cm">
                   <height></height>
                   <width></width>
                   <depth></depth>
                </dimensions>
                <measure unit="xx" quantity="0"/>
             </extent>

             <condition>
                <p></p> <!-- Free text description -->
             </condition>

       </supportDesc>

       <layoutDesc>
          ....
       </layoutDesc>

</objectDesc>

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  
<support>.

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...)

   --elli

[Elli Mylonas
  Brown University Library]