Decorative Arch, Resafa, Syria. Copyright, Daniel Schwartz.

Syriaca.org Documentation

Archive of Deprecated Encoding Standards

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. The use of the <principal> element was deprecated on 5/14/2020.

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

<principal>David A. Michelson</principal>

profileDesc/langUsage

Deprecated encoding was:

         <langUsage>
		<language ident="syr">Unvocalized Syriac of any variety or period</language>
           	<language ident="syr-Syrj">Vocalized West Syriac</language>
           	<language ident="syr-Syrn">Vocalized East Syriac</language>
            	<language ident="en">English</language>
           	<language ident="ar">Arabic</language>
         </langUsage>

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>

srophe:tags="#syriaca-simplified-script"

Previously we marked the creation of Romanizations using srophe:tags="#syriaca-simplified-script" and xml:lang="en-x-srp1". The use of srophe:tags="#syriaca-simplified-script" has been deprecated.

<placeName xml:id="name1003-1" xml:lang="en" srophe:tags="#syriaca-headword" source="#bib1003-1">Beth ʿAynatha</placeName>
                    <placeName xml:id="name1003-2" xml:lang="en" source="#bib1003-2">Beṯ ʿAïnāṯā</placeName>
                    <placeName resp="http://syriaca.org" xml:id="name1003-3" xml:lang="en-x-srp1" srophe:tags="#syriaca-simplified-script">Beth Aynatha</placeName>
                    <placeName resp="http://syriaca.org" xml:id="name1003-4" xml:lang="en-x-srp1" srophe:tags="#syriaca-simplified-script">Beth ‘Aynatha</placeName>
                    <placeName resp="http://syriaca.org" xml:id="name1003-5" xml:lang="en-x-srp1" srophe:tags="#syriaca-simplified-script">Beṯ Aïnāṯā</placeName>
                    <placeName resp="http://syriaca.org" xml:id="name1003-6" xml:lang="en-x-srp1" srophe:tags="#syriaca-simplified-script">Beṯ ‘Aïnāṯā</placeName>

This attribute value was added whenever we created machine generated names as a process of machine Romanization. The namse 3 through 6 here were generated by script based on names 1 and 2. These names DO NOT appear in the HTML view of the record and are generated merely for making it possible for searching by these names which have the diacritics removed or in a different style. The srophe:tags="#syriaca-simplified-script" marks them as being excluded from the HTML.

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.

link with note@type="deprecation"

Previously we used <link> to link deprecation notes to names, now the linking is done in the <note> elements attributes.

In order to mark the <placeName> element as erroneous, we create a <note> element with an @xml:id which is the same as the <placeName> @xml:id with "-deprecation" appended.

In order to link the <note> to the appropriate <placeName>, a <link> element is used with a @target attribute whose value is the @xml:id values for the deprecated <placeName> and the <note> separated by a space.

TEI does not allow <note> and <link> elements before <desc>, <location>, <event>, or <state> elements, so the <note> and <link> indicating the deprecation should occur immediately before the <idno> section. In the event that multiple names need to be deprecated for the same reason, the same <note> can be linked to multiple <placeName> elements.

Such names are visually marked in the html display of the place record, taken out of the list of names and instead listed in the Deprecations section at the bottom of the record, to warn users that these forms are problematic.

Example Code:

<note type="deprecation" xml:id="name518-3-deprecation">
Dolabani's Syriac form was derived from Barsoum's Arabic, but reading a letter baʾ (with one dot) instead of the letter yaʾ (with two dots).
</note>
<link target="#name518-3 #name518-3-deprecation"/>

listRelation/relation/@mutual

Previously the @mutual values in the TEI:relation element could containt pointers to @xml:id values from elsewhere in the file document. This usage (shown in examples in the next section) was deprecated in 2020 to allow only Syriaca.org URIS to facilitate the serialization of linked data triples out of the TEI:relation data.

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.