This section of the EpiDoc Guidelines provides direction for encoding the date of origin of the text (or in some cases, of the object or some other feature, decoration, or reuse of it), whether the result of the editor's analysis or an explicit, internal date. Guidance is also provided on recording possible ranges of dates, named historical periods, degrees of precision and dating criteria.
The date of orgin of the text (or object, if different) should be recorded in an origDate element in the origin section of the manuscript description area (see the general section on provenance for context). If different dates need to be recorded for text and object, different texts on the same support, or different interventions in the same text, the origDate may be repeated, or the entire history may be embedded in multiple msParts.
It is generally recommended to encode the dating information in numerical form, following the proleptic Julian calendar, using the att.datable.custom attributes on the origDate element. These "custom" date attributes are required because the default dating system assumed by the basic TEI date attributes (att.datable) is the Gregorian calendar. Moreover, therefore, the dating element should always carry a datingMethod attribute pointing to a calendar element in the header--or to an external authority for the Julian calendar, such as http://en.wikipedia.org/wiki/Julian_calendar.
A specific date, whether a single day, month, or year in the Julian calendar, can be expressed using the when-custom attribute, which should be laid out in the same form as an ISO 8601/W3C date (albeit in the Julian, not Gregorian calendar). In other words:
A date within a range (such as an event occurring within the reign of an emperor, e.g., the raising of a milestone, or a century for, e.g., palaeographically dated text) should be encoded using the notBefore-custom and notAfter-custom attributes, marking the beginning and end of the possible span of dates. The date formats of these attributes are the same as for when-custom.
This example encodes a simple Julian date:
This example encodes a date occurring within a range, again in Julian calendar:
This example uses the custom dating attributes on the origDate element to express a date in the Julian calendar that is derived from a date recorded on an inscription in the Śaka era. (The calendar attribute records the calendrical system of the date recorded by this element, wheras datingMethod records the system to which the date is normalized in the xx-custom attributes. Normalization would otherwise be assumed to be to the Gregorian calendar.)
Not all texts are dated confidently to a specific year or firm span of years. If a date given is flagged explicitly as less certain than usual (for example, either with a "?" or a formulation such as "just possibly") the origDate may be given a cert attribute with a value of "low". If a date is flagged as approximate (which is different from being uncertain; often written "circa", "ca." or "c.") origDate should be given an precision with a value of low. If a date range is specified (with notBefore-custom and notAfter-custom) whose start and end points are essentially arbitrary, such as a century or half-century for a palaeographical date, then a precision of "medium" should be given, to indicate that the start and end-points are both notional.
In a few cases, a text may be dated within a span of dates with a notional end-point but a firm terminus post quem. To record this in XML, a precision element may be placed inside the origDate to point to whichever of the attributes represents the less concrete end-point. (See third example below.)
You can align your definitions by aligning to a local or to an external Controlled Vocabulary.
In some cases, rather than (or as well as) a specific or approximate numerical date range, scholars will date an inscription by a named historical period, such as "Hellenistic," "Imperial," "Byzantine" or "Early Dynastic." If desired, the historical period may be encoded in the origDate element using the period attribute, pointing to the URI of a vocabulary for historical periods such as PeriodO or a Wikidata entity. (This period need not correspond precisely to the numerical date range offered, if any.)
The criteria for the date given in the origDate element may be expressed in the evidence attribute. The contents of this attribute should be thought of as a series of space-delimited tokens rather than a sentence of prose. That is to say, for example, if the dating of an inscription depends on lettering, nomenclature and partly archaeological context, rather than encoding this as <origDate evidence="lettering, nomenclature and partly archaeological context"> it would be more appropriate to enter: <origDate evidence="lettering nomenclature archaeological-context">. Note that because values in this list are space-delimited, any values that are multi-word phrases should have some symbol, generally hyphen ('-') in place of spaces. Most projects will find it useful to have a typology of criteria with a controlled vocabulary of values for the terms in this attribute.
The EpiDoc schema suggests a short list of values for evidence to encourage consistency. These values are:
As these are only suggestions, there is no prohibition against any project using, e.g., “palaeography” instead of lettering or “onomastics” instead of nomenclature, or indeed use several terms that are more specific subcategories of “material context”. In any case it would be more advisable to maintain an internal table of dating criteria values, with the terms mapped to human-readable language (which might, for example, not be in English). Most projects will define their own lists, or use external LOD vocabularies such as EAGLE, FAIR Epigraphy, Biblissima EpiVoc or Wikidata.
Cf.
This example encodes a certain date within a particular consular year:
Other pages describing <origDate>:
Other pages describing <precision>: