Digital Syriac Corpus Documentation

Archive of Deprecated Encodings

This wiki documents previous TEI encoding practices adopted by Syriaca.org which were subsequently deprecated and (hopefully!) purged from the data. These encoding rules are archived here to assist with understanding or transforming old versions of the Syriaca.org data set.

Deprecated Encodings from the TEI Encoding Manual for The Syriac Gazetteer

titleStmt/principal

Previously, the title statement identified the principal researcher.

Next the principal researcher is identified using the <principal> element:

<principal>David A. Michelson</principal>

revisionDesc/change/@target

The <change> element was previously allowed an optional @target attribute can point to the @xml:id of the particular entry modified. A fictional <revisionDesc> for Edessa might look as follows:

<revisionDesc>
   	<change when="2013-04-15" who="http://syriaca.org/editors.xml#ngibson"
		n="1.1" target="#ng">
ADDED: Pleiades coordinates</change>
   	<change when="2013-04-01"
		 who="http://syriaca.org/editors.xml#dmichelson" target="#dam">
FIXED: Ufra to Urfa</change>
   	<change when="2013-03-16" who="http://syriaca.org/editors.xml#tcarlson"
		 n="1.0">
ADDED: teiHeader/revisionDesc</change>
   	<change when="2013-03-15" who="http://syriaca.org/editors.xml#tcarlson">
		ADDED: teiHeader</change>
   	<change when="2013-03-01" who="http://syriaca.org/editors.xml#tcarlson"
		 n="0.1">
CREATED: place</change>
</revisionDesc>

In this example, later in the document the <place> element would contain the following elements with the @xml:id attributes pointed to here:

<place>
	<!-- … -->
	<placeName xml:id="dam" xml:lang="en" source="#bib78-1">Urfa</placeName>
	<!-- … -->
	<location xml:id="ng" type="gps"
		 source="http://pleiades.stoa.org/places/658457/dare-location">
   		<geo>37.14863 38.786696</geo>
   	 </location>
	<!-- … -->
</place>

A single change which affected multiple XML elements can include space-separated pointers to multiple @xml:id attributes. For example:

<change when="2013-03-16" who="http://syriaca.org/editors.xml#tcarlson" 
		target="#tac1 #tac2 #tac3">
	FIXED: typos in <gi>title</gi> entries within <gi>bibl</gi> elements
</change>

event/label and event/desc

Previously an event could optionally be labeled using a <label> or <desc> element, this was not used and is now deprecated in favor of <p>.

<event notBefore="0079" notAfter="0116">
	<desc xml:lang="en">Changed course to run between Kokhe and
	Ctesiphon rather than between Kokhe and Seleucia</desc>
</event>

On the other hand, the council of Chalcedon ran from Oct. 8 to Nov. 1, 451, so an <event> within the <place> for Chalcedon could read as follows:

<event from="0451-10-08" to="0451-11-01">
		<desc xml:lang="en">Site of Ecumenical Council</desc>
</event>

If the event took place before the common era, a negative sign should precede the four-digit year (e.g. “-0304” for 304 BCE). For example, according to GEDSH, in 304 BCE the Macedonian general turned Mesopotamian ruler Seleucus I Nicator renamed the city of Urhoy “Edessa” after a Macedonian city of that name. This event could be encoded:

<event when="-0304" source="#bib78-1">
	<desc xml:lang="en">Renamed Edessa by Seleucus I Nicator.</desc>
</event>

Example: For name attestations, the contents of the <event> element should simply be <label>Attestation of name {placeName} in {Author}, {title-of-work}</label>. For confession attestations, the contents of the <event> element could similarly be <label>Attestation of confession {name} in {Author}, {title-of-work}</label>. Alternately the <label> element could provide more precise indication of what exactly is attested, which we are taking as evidence for a religious community. For example, <label>Attestation of Chalcedonian author in Edessa according to the Chronicle of Edessa.</label> might be linked to the confession “Melkite.” While this content is redundant and not machine-readable, it will facilitate human proofreading.

listRelation/relation/@name

Previously, relationships between places were documented using <relation type="contains">, but now we use <location type="nested">. Similarly, <relation type="resided"> was used to indicate that a person lived in a place, but that use is now deprecated as well.

The <relation> element is very general. It has a mandatory @name attribute whose value is the relationship (it can be thought of as the “verb” in the sentence, but it is not allowed to contain any spaces). If the relationship is mutual, then pointers to the entities among which this relationship holds are given as space separated values in a @mutual attribute. Otherwise, if there is a subject and object in this relationship, pointer(s) to the subject(s) are given as space separated values in the @active attribute and pointer(s) to the object(s) are given in the @passive attribute. These pointers can be URIs for the entity in question, or pointers to @xml:id values from elsewhere in this document. Finally, a human-readable sentence describing the relationship, which is useful for proofreading and for having something to display to other humans, can be encapsulated in a <desc> child element with the language specified by an @xml:lang.

Example 1: according to GEDSH Map 1, Edessa was within the Roman province of Osrhoene (http://syriaca.org/place/145), within the Roman Empire (http://syriaca.org/place/166). These relationships could be encoded as follows, in the file 78.xml, which identifies Edessa by the @xml:id “place-78”:

<listRelation>
<relation name="contains" 
	active="http://syriaca.org/place/145" 
	passive="#place-78"
	source="#bib78-1">
	<desc xml:lang="en">Another place contains this place.</desc>
</relation>
<relation name="contains" 
	active="http://syriaca.org/place/166" 
	passive="#place-78"
	source="#bib78-1">
	<desc xml:lang="en">Another place contains this place.</desc>
</relation>
</listRelation>

On the other hand, because the relation is the same, these two <relation> elements could be condensed as follows:

<relation name="contains" 
	active="http://syriaca.org/place/145 http://syriaca.org/place/166" 
	passive="#place-78"
	source="#bib78-1">
	<desc xml:lang="en">Other places contain this place.</desc>
</relation>

Note that the @name of the <relation> does not experience inflection to reflect the plural subject.

Example 2: in the TEI document describing Edessa, the relationship that Ephrem (http://syriaca.org/person/13) resided in Edessa might be represented as follows:

<relation name="resided" 
	active="http://syriaca.org/person/13" 
	passive="#place-78">
	<desc xml:lang="en">A person resided at this place.</desc>
</relation>

Relations can also be annotated with dates using the same attributes (@when, @notBefore, @notAfter, @from, and @to) used to indicate the dates of events, as described above under the <event> element. Since Ephrem resided in Edessa from 363 until his death on June 9, 373, this information can be encoded as follows:

<relation name="resided" 
	active="http://syriaca.org/person/13" 
	passive="#place-78"
	from="0363" to="0373-06-9">
	<desc xml:lang="en">A person resided at this place.</desc>
</relation>

Citations of the source of this asserted relationship can be encoded using the @source attribute with reference to the @xml:id attributes of <bibl> elements in the document. Since <bibl> elements cannot be contained within the <relation> or <listPlace> elements, it makes sense to include all <bibl> elements within the <place> element which is a sibling to the <relation>. Since the assertion that Ephrem resided in Edessa is derived from GEDSH, the total relation might look something like this:

<relation name="resided" 
	active="http://syriaca.org/person/13" 
	passive="#place-78"
	from="0363" to="0373-06-9"
	source="#bib78-1">
	<desc xml:lang="en">A person resided at this place.</desc>
</relation>

Although it is possible to express relationships between places and persons in the TEI markup for a place record, as a policy decision, Syriaca.org will include such relationships in the TEI markup for the person record instead.