Digital Syriac Corpus Documentation

Table of Contents

Overview

The TEI Header

<fileDesc>

<titleStmt>

<editionStmt>

<publicationStmt>

<sourceDesc>

<encodingDesc>

<editorialDecl>

<classDecl>

<revisionDesc>

Planned Revisions using <change type=”planned”> (optional)

The Body of the Text: <listPlace>

<place>

<bibl>

<placeName>

@xml:lang

@source

Normalizations

<desc>

<location>

<event> (optional)

Attestations using <event> (optional)

Duration of place using <state>

Confessions using <state type=“confession”> (optional)

Erroneous Names using <note> (optional)

Erroneous and uncertain assertions using <note> (optional)

Disambiguation using <note> (optional)

<idno>

Relationships using <relation>

Overview

The Syriac Gazetteer is a geographical reference work of Syriaca.org for places relevant to Syriac studies. For each place there is a brief description; other, optional, features include Events and Attestations. Each place record is encapsulated in a <place> element within a <listPlace> element within the <body> of a TEI document. The majority of the content of the <teiHeader> will be standard across all places, but some elements will be specific to this place or this TEI file. The structure of every TEI file for Syriaca.org places should look as follows, with the parts relevant to individual places indicated by ellipses [...].

<?xml-model href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" schematypens="http://relaxng.org/ns/structure/1.0"?>
<TEI
	xml:lang="en"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:math="http://www.w3.org/1998/Math/MathML"
	xmlns="http://www.tei-c.org/ns/1.0">
   <teiHeader>
    	<fileDesc>
        	<titleStmt>
			<title level="a" xml:lang="en">...</title>
			<title level="m" xml:lang="en">The Syriac Gazetteer</title>
            		<sponsor>Syriaca.org: The Syriac Reference Portal</sponsor>
            		<funder>...</funder>
            		<principal>David A. Michelson</principal>
            		<editor role="general" ref="...">...</editor>
			<editor role="creator" ref="...">...</editor>
			...
          		<respStmt>
				<resp>... by</resp>
				<name>...</name>
      			</respStmt>
			...
        	</titleStmt>
        	<editionStmt>
            		<edition n="1.0"/>
        	</editionStmt>
        	<publicationStmt>
            		<authority>Syriaca.org: The Syriac Reference Portal
			</authority>
            		<idno type="URI">http://syriaca.org/place/.../tei</idno>
      			<availability>
                		<licence
                                 target="http://creativecommons.org/licenses/by/3.0/">
                    		<p>Distributed under a Creative Commons Attribution 3.0 Unported License</p>
                                 ...
 	               	        </licence>
            		</availability>
            		<date>...</date>
                </publicationStmt>
        	<sourceDesc>
            		<p>Born digital.</p>
        	</sourceDesc>
    	</fileDesc>
	<encodingDesc>
		<editorialDecl>
			<p>Normalized capitalization of GEDSH names.</p>
			...
	        </editorialDecl>
		<classDecl>
			<taxonomy>
				<category xml:id="syriaca-headword">
					<catDesc>The name used by Syriaca.org for document titles, citation, and disambiguation. While headwords are usually created from primary source citations, those without source attributes may not be attested in extant sources. They are included only to aid the reader for the purpose of disambiguation. These names have been created according to the Syriac.org guidelines for headwords: <ref target="http://syriaca.org/documentation/headwords">
http://syriaca.org/documentation/headwords</ref>.</catDesc>
				</category>
				...
			</taxonomy>
		</classDecl>
</encodingDesc>
	<profileDesc>
         <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>
	</profileDesc>
    	<revisionDesc>
		...
        	<change who="..." n="1.0" when="..."> CREATED: place </change>
    	</revisionDesc>
   </teiHeader>
   <text>
    	<body>
        	<listPlace>
            		<place>
				...
			</place>
			...
        	</listPlace>
    	</body>
   </text>
</TEI>

In addition to the core elements described above, a place record may optionally contain additional information indicating events which happened in or to that place, religious affiliations, attestations of a name in a primary source, indications that a name is erroneous, or relationships to other places. Confessional affiliations and events will be indicated by elements within a <place> element, respectively by <state> and <event> elements. Attestations will be encapsulated within an <event> which is linked to the <placeName> by a <link> element, while erroneous names will be indicated by a <note> which is linked to the name. Relationships can be encoded using a sibling of the <place> element within the <listPlace> element, namely <relation>.

The TEI Header

The <teiHeader> is a mandatory element of every TEI file, and it encodes important information about the process which created this file. Every <teiHeader> element contains a <fileDesc> element (information about the creation of a file), an <encodingDesc> element (editorial rules), a <profileDesc> element (non-bibliographic aspects of a text), and a <revisionDesc> element (history of revisions).

<fileDesc>

Each <fileDesc> element contains (in order) a <titleStmt>, an <editionStmt>, a <publicationStmt>, and a <sourceDesc>.

<titleStmt>

The purpose of the title statement <titleStmt> is not only to provide the title of the place, but also to identify parties responsible for the creation of a file. The <titleStmt> must contain a <title> element which contains the title for this place, with an @xml:lang attribute specifying the language of the title. The title for each individual place record also has an attribute @level with value “a” to distinguish it from the title of the entire project (e.g. The Syriac Gazetteer). The “a” value stands for analytic, which means that the title is part of a larger publication. Every place entry should have a title which includes an English and Syriac place name as a headword. (Headwords are discussed in detail below. These headwords are not necessarily a preferred name for the place. Syriaca.org designates one Syriac and one English “headword” for each place, as a convention to allow users to browse and search entries by alphabetical order.) This title will not always be unique (e.g. multiple cities named "Seleucia," multiple monasteries of "Mor Zakkay"), but that will not matter since the filename is based on the unique URI. Thus, the <title> for Edessa would be:

<title level="a" xml:lang="en">Edessa — 
       <foreign xml:lang="syr">ܐܘܪܗܝ</foreign></title>

Every place record should also have a title specifying that it is part of The Syriac Gazetteer, which should look as follows:

<title level="m" xml:lang="en">The Syriac Gazetteer</title>

The “m” value indicates that this level is monographic (at the level of the entire project).

The TEI guidelines recommend that the <titleStmt> element also indicate who is responsible for this TEI file. Since <author> is typically used for the author of a print or manuscript text which was then encoded in TEI, we avoid the use of the <author> element. Instead, we identify Syriaca.org as the sponsoring institution, as follows:

<sponsor>Syriaca.org: The Syriac Reference Portal</sponsor>

Next within the <titleStmt> the funding bodies are identified by use of the <funder> element. If multiple funding bodies are relevant, then each one gets a separate <funder> element, which are simply listed. For example, the initial entries of The Syriac Gazetteer were funded by the National Endowment for the Humanities and the International Balzan Prize Foundation, so the funding section looks like this:

<funder>The National Endowment for the Humanities</funder>  
<funder>The International Balzan Prize Foundation</funder>

Next the principal researcher is identified using the element:

<principal>David A. Michelson</principal>

The general editors for this domain of Syriaca.org are then listed in successive <editor> elements, each with a @role attribute with value “general” and a @ref attribute which points to the @xml:id of the editor within the “editors.xml” document. The name of the general editor is the content of the <editor> element. The parties responsible for the creation of the initial TEI for this entry are then listed in <editor> elements similarly with a @role attribute having value “creator”. Editors who modify the TEI for a place after it has been created should be listed in <editor> elements with @role=”entry-editor”. There may be duplicates between general editors and either creators or entry editors. So the editors for the place record for Edessa (http://syriaca.org/place/78) would look as follows:

<editor role="general" ref="http://syriaca.org/editors.xml#tcarlson">
		Thomas A. Carlson</editor>
<editor role="general" ref="http://syriaca.org/editors.xml#dmichelson">
		David A. Michelson</editor>
<editor role="creator" ref="http://syriaca.org/editors.xml#tcarlson">
		Thomas A. Carlson</editor>
<editor role="creator" ref="http://syriaca.org/editors.xml#dmichelson">
		David A. Michelson</editor>

Other parties who are responsible for the creation of this TEI place record are then identified individually in <respStmt> elements (<resp> stands for “responsibility”). The contents of the <respStmt> element are the description of the responsibility wrapped in a <resp> element followed by the name of the responsible party contained in a <name> element. The <name> element should take a @ref attribute which points to the @xml:id of the editor within the “editors.xml” document. Additional participants in the creation of the file, for example by entering Syriac or Arabic text, can be given additional <respStmt> entries. In this case, the full <titleStmt> of the TEI file containing Edessa might look as follows:

<titleStmt>
	<title xml:lang="en">Edessa</title>
     	<sponsor>Syriaca.org: The Syriac Reference Portal</sponsor>
     	<funder>The National Endowment for the Humanities</funder>
     	<funder>The International Balzan Prize Foundation</funder>
     	<principal>David A. Michelson</principal>
     	<editor role="general" ref="http://syriaca.org/editors.xml#tcarlson">
		Thomas A. Carlson</editor>
        <editor role="general" ref="http://syriaca.org/editors.xml#dmichelson">
		David A. Michelson</editor>
        <editor role="creator" ref="http://syriaca.org/editors.xml#tcarlson">
		Thomas A. Carlson</editor>
        <editor role="creator" ref="http://syriaca.org/editors.xml#dmichelson">
		David A. Michelson</editor>
     <respStmt>
      	<resp>Initial Barsoum entry creation by</resp>
      	<name ref="http://syriaca.org/editors.xml#dmichelson">
			David A. Michelson</name>
     </respStmt>
     <respStmt>
       	<resp>Data merging, Pleiades and Wikipedia linking, and XML
			by</resp>
           <name ref="http://syriaca.org/editors.xml#tcarlson">
			Thomas A. Carlson</name>
     </respStmt>
     <respStmt>
       	<resp>Syriac description entry by</resp>
        	<name ref="http://syriaca.org/editors.xml#raydin">
			Robert Aydin</name>
     </respStmt>
     <respStmt>
          	<resp>Arabic description entry by</resp>
        	<name  ref="http://syriaca.org/editors.xml#rakhrass">
			Dayroyo Roger-Youssef Akhrass</name>
     </respStmt>
</titleStmt>

<editionStmt>

The <editionStmt> allows the specification of an edition or version number. When a TEI file is first published online, that edition should be “1.0”. Subsequent revisions may bump the revision number, either by a whole new version (i.e. to “2.0”) or by a minor version (i.e. to “1.1”). This is encoded as follows:

<editionStmt>
       <edition n="1.0"/>
</editionStmt>

<publicationStmt>

The <publicationStmt> is where we identify Syriaca.org as the entity responsible for publishing this information, indicate the date of the most recent edit, and identify the use license (Creative Commons CC-BY). The identification of Syriaca.org as the responsible entity is accomplished by an <authority> element:

<authority>Syriaca.org: The Syriac Reference Portal</authority>

The URI for this particular file, as distinct from the URI for the entity described by this record, is encapsulated in an <idno> element with @type=”URI”. In general the URI for this file will be generated by appending “/tei” to the URI for the entity described in this record. For the example of Edessa (place/78), this looks as follows:

<idno type="URI">http://syriaca.org/place/78/tei</idno>

The <license> element within the <availability> element is used to specify the Creative Commons CC-BY license under which this record is made available. Some records incorporate information from works under copyright (with permission), a fact which is also indicated in the <license> element. For example, in the case of Edessa, with pointers to the citations of these copyrighted works (see <bibl> below):

<license target="http://creativecommons.org/licenses/by/3.0/">
  <p>Distributed under a Creative Commons Attribution 3.0 Unported License.</p>
  <p>This entry incorporates copyrighted material from the following work(s):
	<listBibl>
		<bibl>
			<ptr target="#bib78-3"/>
		</bibl>
		<bibl>
			<ptr target="#bib78-4"/>
		</bibl>
		<bibl>
			<ptr target="#bib78-5"/>
		</bibl>
	</listBibl>
	<note>used under a Creative Commons Attribution license
		<ref target="http://creativecommons.org/licenses/by/3.0/"/>
	</note>
  </p>
</licence>

Finally, the date of the record indicates its most recent modification, giving the current date within a <date> element. With the exception of the record URI, the date, and the possible inclusion of a notice regarding other copyrighted material, the <publicationStmt> should be identical in all Syriaca.org records. Here is a complete example for Acre (place/14), which does not incorporate material under copyright elsewhere:

<publicationStmt>
	<authority>Syriaca.org: The Syriac Reference Portal</authority>
	<idno type="URI">http://syriaca.org/place/14/tei</idno>
	<availability>
		<licence target="http://creativecommons.org/licenses/by/3.0/">
			<p>Distributed under a Creative Commons 
			Attribution 3.0 Unported License.</p>
		</licence>
	</availability>
	<date>2014-01-14-05:00</date>
</publicationStmt>

<sourceDesc>

The <sourceDesc> element is also a mandatory component of the <fileDesc> element. Its purpose is to indicate the source of the text which is encoded in this file, for library cataloging among other uses. For The Gazetteer, which is not marking up text from a source, the option of indicating that this TEI is “born digital,” should be used:

<sourceDesc>
 	<p>Born digital.</p>
</sourceDesc>

<encodingDesc>

The <encodingDesc> element of the <teiHeader> is used for indicating aspects of the process of encoding the text. Although our person and place data are “born digital,” they nevertheless have certain editorial decisions regarding how they have used data derived from print resources, and certain tags available for use in our @syriaca-tags attribute. Those sorts of details are encoded here.

<editorialDecl>

The first element within an <encodingDesc> is the <editorialDecl>, which indicates editorial decisions regarding how the source documents were handled. An <editorialDecl> cannot directly contain prose, so a prose description of each editorial decision should be wrapped in a <p> element. References to particular bibliographic entries can have their Syriaca.org URIs wrapped in an <idno> for specificity. The first <p> element should contain a pointer to the Syriaca.org documentation. For example:

<encodingDesc>
	<editorialDecl>
		<p>This record created following the Syriaca.org guidelines. Documentation available at: <ref target="http://syriaca.org/documentation">
http://syriaca.org/documentation</ref>.</p>
<p>The capitalization of names from GEDSH (<idno type="URI">http://syriaca.org/bibl/1</idno>) was normalized (i.e. names in ALL-CAPS were replaced by Proper-noun capitalization).</p>
<p>The unchanging parts of alternate names from Barsoum (<idno type="URI">http://syriaca.org/bibl/2</idno>, <idno type="URI">http://syriaca.org/bibl/3</idno>, or <idno type="URI">http://syriaca.org/bibl/4</idno>) have been supplied to each alternate.</p>
<p>Names from the English translation of Barsoum (<idno type="URI">http://syriaca.org/bibl/4</idno>) were put in sentence word order rather than fronting a dictionary headword.  Any commas in the Barsoum name in English were removed.</p>
<p>The <gi>state</gi> element of @type="existence" indicates the period for which this place was in use as a place of its indicated type (e.g. an inhabited settlement, a functioning monastery or church, an administrative province).  Natural features always in existence have no <gi>state</gi> element of @type="existence".</p>
		...
	</editorialDecl>
	...
</encodingDesc>

<classDesc>

The class declaration contains one or more taxonomies defining any classificatory codes used elsewhere in the text. There are various tags which Syriaca.org uses to mark elements for a variety of purposes. Syriaca.org’s preferred name forms are tagged with “syriaca-headword”, for example. These tags are represented by <category> elements within a <taxonomy> element within a <classDecl> element after the <editorialDecl> element within the <encodingDesc>. Each <category> has an @xml:id attribute whose value is the tag. Within the <category> element is a <catDesc> element which contains a brief prose description of the category’s purpose. For example, the encoding of “syriaca-headword” might look as follows:

<classDecl>
	<taxonomy>
		<category xml:id="syriaca-headword">
			<catDesc>The name used by Syriaca.org for document titles, citation, and disambiguation. These names have been created according to the Syriac.org guidelines for headwords: <ref target="http://syriaca.org/documentation/headwords.html">http://syriaca.org/documentation/headwords.html</ref>.</catDesc>
		</category>
	</taxonomy>
</classDecl>

<revisionDesc>

After the <fileDesc> element, the final part of the TEI header is the <revisionDesc> element, which is used to include a detailed log of which changes have been made to this file, when, and by whom. Each revision is encapsulated in a <change> element, ordered from newest to oldest. The <change> element takes attributes @when and @who which indicate the date of the change and the person who made the change. The value of @when is a date in “yyyy-mm-dd” format, whereas @who will have the value of an @xml:id attribute from “http://syriaca.org/editors.xml” - the list of editors. An optional @n attribute whose value is a version number can indicate that this change advanced the version number (given in the <editionStmt> within the <fileDesc> element). The contents of the <change> element describe the revision that was made. While there are no TEI requirements for the content, Syriaca.org could adopt a controlled vocabulary of what was done to the modified entry. 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">
ADDED: Pleiades coordinates</change>
   	<change when="2013-04-01"
		 who="http://syriaca.org/editors.xml#dmichelson">
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>

Planned Revisions using <change type=”planned”> (optional)

In some cases there is work which is planned but not yet completed. In order to leave a note to future editors that some aspect of the markup has not been completed, but is planned, a <change> element is inserted at the beginning of the <revisionDesc> in the <teiHeader> with @type=”planned”. A @subtype attribute will be used to provide a machine-extractable identification of this planned revision across multiple place records.

For example, a plan to include Armenian names for those places mentioned in the Armenian translation of the Chronicle of Michael the Great might be represented:

<change type="planned" subtype="armenian">
	Add Armenian place names from Armenian Michael the Great (Langlois ed.)
</change>

As a second example, an intention to identify the personal and place names mentioned in the Barsoum descriptions of each place, adding pointers to the Syriaca.org URIs for those people or places, might be indicated as follows:

<change type="planned" subtype="Barsoum-desc-markup">
	Identify person/place names in Barsoum descriptions, with Syriaca URIs
</change>

In the future, when a planned revision is executed, the @type and @subtype can be deleted, and the information indicating who completed the revision when (@who, @when) added, to turn the planned revision into a past revision.

The Body of the Text: <listPlace>

<place>

Within the <listPlace> element within the <body> element of the <text> element, each <place> element will have an @xml:id attribute set with the value “place-{\d+}” where the final digits are the SRP id # for the place (i.e. the final element in the URI). The “{\d+} is a regular expression which signals that one or more (+) digits (d) be found. Each <place> element will also have a @type attribute indicating what type of place it is. For places derived from GEDSH (Gorgias Encyclopedic Dictionary of the Syriac Heritage) map data, the value of the @type attribute will be related to the map type, although perhaps generalized (e.g. “medium city” -> “settlement”), and in any case the values of the @type attribute will be taken from a controlled vocabulary. See the Syriaca.org controlled vocabulary for acceptable values of the @type attribute here. So the skeleton of a <place> element for Edessa might look as follows:

<place xml:id="place-78" type="settlement">
</place>

Within each <place> element will be:

  1. a series of <placeName> elements
  2. one or more <desc> description elements
  3. zero or more <location> elements
  4. zero or more <event elements
  5. zero or more <state> elements
  6. zero or more <note> elements
  7. one or more <idno> elements
  8. one or more <bibl> elements

Each category of elements will be described in order with the exception of the <bibl> elements, which will be discussed first so that they can be referenced by other elements.

<bibl>

The <bibl> elements are used to indicate bibliographic items cited elsewhere within this record. These <bibl> elements will be referred to by @source attributes in the <placeName>, <quote>, and <location> elements contained in the same <place> element.

Each <bibl> element will have an attribute @xml:id whose value is set to bib{\d+}-{\d+}, where the first number is the SRP id # for the place (i.e. the final element in the URI) and the second number is the consecutive number of this <bibl> element in the series of <bibl> elements contained in this place, counting from 1. For example, the first <bibl> element within the place record describing Edessa (http://syriaca.org/place/78) will be <bibl xml:id="bib78-1"/>.

Contained within the <bibl> element is a <ptr> element whose @target attribute has the value of a URI pointing to the bibliographic item. URIs for bibliographic items have been assigned in this document. For example, if the first <bibl> element in the place record for Edessa encodes a reference to GEDSH, it might look like the following:

<bibl xml:id="bib78-1">
     <ptr target="http://syriaca.org/bibl/1"/>
</bibl>

If a page number is included in the citation, it is contained in a <citedRange> element whose @unit attribute has the value “pp”. If the third <bibl> element in the place record for Edessa represents a reference to page 556 of the Syriac translation of Afram Barsoum’s Scattered Pearls, it could be encoded like this:

<bibl xml:id="bib78-3">
   <ptr target="http://syriaca.org/bibl/3"/>
   <citedRange unit="pp">556</citedRange>
</bibl>

As long as a <ptr target> with a Syriaca.org URI, e.g. "http://syriaca.org/bibl/3" is present, such a short citation is sufficient to allow the Srophé app to generate complete footnotes for every citation in the XML place record based on the TEI record in the bibliography module, e.g. http://syriaca.org/bibl/3/tei. This short citation is, however, opaque to human editors of the XML place record. To aid human readability, therefore, each record sould add a <title> element to each <bibl> with an @xml:lang attribute indicating the language of the title. This <title> can be added by the human editor or if it is not, it must be added by an automated script after creation of the record but before publication. Thus the previous two examples of <bibl> usage in the record for Edessa would be completed as follows:

<bibl xml:id="bib78-1">
		<title xml:lang="en">
			The Gorgias Encyclopedic Dictionary of the Syriac Heritage
		</title>
		<ptr target="http://syriaca.org/bibl/1"/>
		<citedRange unit="pp">138-139</citedRange>
	</bibl>
	<bibl xml:id="bib78-3">
		<title xml:lang="syr">ܒܪ̈ܘܠܐ ܒܕܝܪ̈ܐ ܕܥܠ ܡܪܕܘܬ ܝܘܠܦܢ̈ܐ ܣܘܪ̈ܝܝܐ ܗܕܝܪ̈ܐ
		</title>
		<ptr target="http://syriaca.org/bibl/3"/>
		<citedRange unit="pp">556</citedRange>
	</bibl>

<placeName>

Each <placeName> element will contain the text of a name for this place as recorded in the source from which the name is taken, with certain exceptions (see below). Each <placeName> element should have an @xml:id whose value is the concatenation of “name”, the Syriaca.org ID number of this place (i.e. the last element of the URI), a ‘-’, and the number of this name element in order. Thus the fourth <placeName> element for Edessa (place/78) will have @xml:id=”name78-4”. This @xml:id will be used to indicate which names have attestations encoded in the TEI file or are marked as dubious in some way.

@xml:lang

The language of the name should be indicated in an @xml:lang attribute of the <placeName> element, whose value is derived from the the ISO-639-1 or ISO-639-2 standards. In particular, “en” should be used for “English”, “ar” for “Arabic”, and “syr” for Syriac. Syriaca.org is not using “syc” for Syriac to avoid the judgment of what constitutes “classical.” In the case of vocalized Syriac, the @xml:lang attribute should be augmented with a script indication: either “-Syrj” to indicate West Syrian vocalization or “-Syrn” to indicate East Syrian vocalization. Thus the @xml:lang attribute will have a value of “syr-Syrj” for vocalized Western Syriac and “syr-Syrn” for vocalized Eastern Syriac. The @xml:lang attribute for an unvocalized Syriac name form, such as Syriaca.org’s headword form, should be simply “syr”.

@source

The source of a place name is indicated by a @source attribute of the <placeName> element, whose value is a pointer to an xml:id of one of the <bibl> elements at the foot of the element (i.e. an xml:id preceded by a ‘#’ character). For example, Edessa’s modern name “Urfa” is given on the authority of GEDSH (which is represented by the <bibl> element whose @xml:id is “bib78-1”) in the following way:

<placeName xml:id="name78-2" xml:lang="en" source="#bib78-1">
	Urfa
</placeName>

If an identical name is contained in multiple sources, the value of the @source attribute is the list of all sources delimited by spaces. The name “Edessa” is contained in four separate sources, so it is encoded as follows:

<placeName xml:id="name78-1" xml:lang="en"
	source="#bib78-1 #bib78-2 #bib78-5 #bib78-6">
	Edessa
</placeName>

Syriaca.org designates one English name and (where available) one Syriac name as preferred name forms for use in headers, search result lists, etc. These Syriaca.org preferred name forms are indicated by an attribute @syriaca-tags of the <placeName> element whose value is “#syriaca-headword”. Since “Edessa” is also the Syriaca.org headword for this place, the markup for this place name looks as follows:

<placeName xml:id="name78-1" xml:lang="en"
	syriaca-tags="#syriaca-headword"
	source="#bib78-1 #bib78-2 #bib78-5 #bib78-6">
	Edessa
</placeName>

It sometimes happens that a place name was generated by Syriaca.org for consistency of transcription, without having been derived from a print resource. In that case alone, no @source attribute may be given. Instead, a @resp attribute should be included with the value “http://syriaca.org”. For example, the English headword of http://syriaca.org/place/518 is “Mount Qāsiyūn”, which was not found in any of the reference sources so far consulted. This place name is therefore marked up as follows:

<placeName xml:id="name518-1" xml:lang="en" resp="http://syriaca.org">
		Mount Qāsiyūn
</placeName>

In the future, it may be a desirable feature to annotate each place name by time of usage, either by some indication of (potentially multiple) periods of use or through some other means. This is not a feature we are pursuing for our initial release, however.

Normalizations

GEDSH maps presented certain names in ALL-CAPS; the capitalization of these names has been normalized. In places where Barsoum gives alternate name forms, these names have been split into multiple <placeName> elements, and unchanging elements of the name have been populated in each element. For two examples, for Dayro d-Boʿut (place/344) Barsoum gave the name as "دير باعوث او بني باعوث," which was encoded as دير باعوث and دير بني باعوث, and Qidr Monastery (place/376) was listed as "Qidr (or Qidar) Monastery," which was encoded as <placeName>Qidr Monastery</placeName> and <placeName>Qidar Monastery</placeName>. Finally, names from Matti Moosa’s English translation of Barsoum’s Scattered Pearls sometimes needed to be re-ordered to be placed in sentence word order rather than dictionary headword order. So for Kallinikos (place/109), Moosa’s heading "Raqqa, al-" was entered as <placeName>al-Raqqa</placeName>, and for Dayr al-Ṣalīb (place/68) the heading "Cross, Monastery of the" was entered as <placeName>Monastery of the Cross</placeName>. Any commas which occurred in Moosa’s English translation of Barsoum’s Arabic name have been removed as superfluous.

<desc>

Each place should have a brief (1-2 line) prose description which could be used to pick this place out of a lineup of search results. These should be encapsulated within a element with the @xml:id attribute set to “abstract-en-” followed by the Syriaca.org id # (i.e. the final digits in the URI). It should also have an @xml:lang attribute set to the language of this abstract. If the abstract comes from a print source, then it should be encapsulated by a element within the <desc> element, just as for prose descriptions from Barsoum or GEDSH as described below.

If there are other prose descriptions (from Barsoum, for example, or the GEDSH entry heading), these are encapsulated within a <quote> element contained within a <desc> element. The <quote> element should have a @source attribute whose value points to the bibliographic item from which this prose description is taken, while the <desc> element should have an @xml:lang attribute whose value identifies the language of the description.

Example 1: The GEDSH entry heading for Edessa:

<desc xml:lang="en">
   		 <quote source="#bib78-1">183. Edessa</quote>
   	</desc>

Example 2: The description of Edessa on page 516 of the Arabic translation of Afram Barsoum’s Scattered Pearls, with its accompanying bibliographic item:

<desc xml:lang="ar">
   		 <quote source="#bib78-4">مدينة مشهورة خمسة ايام عن
 حلب شرقا وتسمى اليوم اورفه.</quote>
   	</desc>
<bibl xml:id="bib78-4">
   		 <ptr target="http://syriaca.org/bibl/2"/>
   		 <citedRange unit="pp">516</citedRange>
</bibl>

In an actual place TEI file, other elements will come between this <desc> and this <bibl>, such as any locations and the URIs for this place, as well as the three earlier <bibl> elements in this place.

<location>

If there is location information for this place, it should be encoded within one or more <location> items. Each <location> item should have a @source attribute whose value points to the bibliographic item from which this location information was taken. Depending on the nature of the location description, the <location> item can have different contents. If the location is specified as a latitude-longitude coordinate pair, these numbers should be separated by a space with the latitude preceding the longitude and the pair encapsulated within a <geo> element within the <location> element. It is possible to use different earth-coordinate systems, but the default one is the typical latitude and longitude system WGS-1984. For example, a latitude-longitude pair for Edessa, taken from the GEDSH map data, could be represented as follows:

<location type="gps" source="bib78-1">
   		 <geo>37.15 38.8</geo>
   	</location>

In the event that the record encodes multiple latitude and longitude coordinates (for example from different sources), each set of coordinates should be encoded in a separate <location> element. To inform the app which coordinates to use for mapping, the preferred <location> element must be marked with @subtype = "preferred". This is required whenever more than one <location> element has coordinate data. This does not apply to "relative" or prose location descriptions.

If the location is relative to another location, for example contained in the description of the place given by Barsoum, then the location description should be marked up. First, the place name relative to which this current place is located should be encapsulated within a <placeName> element; this <placeName> element should have a @ref attribute whose value is the Syriaca.org URI of the place. A measured distance (both the number and the units) should be encapsulated within a <measure> element, which can also take @unit and @quantity attributes whose values match the encapsulated text. An indication of direction or other terms of relative location (e.g. “near”, “overlooking”) should be encapsulated in an <offset> tag.

To give an example of a relative location extracted from a prose description, the English translation of Barsoum describes Edessa as “a famous city, five day journey eastward from Aleppo, now called Urfa.” The fame of the city and its modern name are not relevant to the location, but “five day journey eastward from Aleppo” is a relative location. This information is encoded twice. In the first place, Barsoum’s description is encoded as a <desc> element as described above:

<desc xml:lang="en">
	<quote source="#bib78-2">a famous city, five day journey eastward from
	Aleppo, now called Urfa.</quote>
</desc>

Then the relative location is added to the TEI based on this description. Step 1 is to mark up the name of the other place:

<location type="relative" source="#bib78-2">
five day journey eastward from 
	<placeName ref="http://syriaca.org/place/18">Aleppo</placeName>
</location>

The next step is to mark up the unit of distance. In this case, the quantity is five, and the unit is the amount of distance one can travel in a day (a “day’s journey”, but since the value of the @unit attribute needs to exclude spaces, a “day-journey”). This example becomes:

<location type="relative" source="#bib78-2">
	<measure unit="days-journey" quantity="5">five day journey</measure>
eastward from 
	<placeName ref="http://syriaca.org/place/18">Aleppo</placeName>
</location>

The direction indicator “eastward from” can be encapsulated in an <offset> element, giving the final location encoding:

<location type="relative" source="#bib78-2">
	<measure unit="days-journey" quantity="5">five day journey</measure>
	<offset>eastward from</offset>
	<placeName ref="http://syriaca.org/place/18">Aleppo</placeName>
</location>

Finally, in order to make explicit that this is a verbatim quotation from the cited source (and thus forestall requests for clarification about the mode of travel we envisage), we use an attribute @subtype=”quote”. This will allow the production of human-readable records which wrap this location information in quotation marks, and will distinguish it from relative locations were are derived from cited resources without reproducing a verbatim quotation. The final resultant encoding is:

<location type="relative" subtype="quote" source="#bib78-2">
	<measure unit="days-journey" quantity="5">five day journey</measure>
	<offset>eastward from</offset>
	<placeName ref="http://syriaca.org/place/18">Aleppo</placeName>
</location>

Since this information is contained in Barsoum’s description of Aleppo, which is also included elsewhere, it is in effect included in the place entry twice, but marked up differently for two different purposes. Thus a longer example showing this text encoded as both a <desc> and as a <location>, both citing the English translation of Barsoum, might look like this:

<desc xml:lang="en">
<quote source="#bib78-2">a famous city, five day journey eastward 
from Aleppo, now called Urfa.</quote>
</desc>
<location type="relative" subtype="quote" source="#bib78-2">
	<measure unit="days-journey" quantity="5">five day journey</measure>
	<offset>eastward from</offset>
	<placeName ref="http://syriaca.org/place/18">Aleppo</placeName>
</location>
<bibl xml:id="bib78-2">
	<ptr target="http://syriaca.org/bibl/4"/>
	<citedRange unit="pp">553</citedRange>
</bibl>

If there are different GPS coordinates based on different sources, these should be put in different <location> elements rather than in multiple <geo> elements within a single <location> (which would imply they are “really the same place in the universe, but with different systems used to refer to it” according to TEI Guidelines 13.3.4.1). The TEI guidelines recommend using a @type attribute when multiple locations are different ways of describing the same place.

In the data from Wilmshurst’s geographic index, a place is often indicated in the context of larger places which contain it. For example, “Beni Shmūni, Arāden, Ṣapnā district, ʿAmādīyā region, 138” in the list of churches indicates the city containing this church of Beni Shmūni, the name of the smaller region containing that city, and the name of the larger region containing that city. This information can be encoded in a <location> element of @type=”nested” as follows:

<location type="nested" source="#bibX-1">
		<settlement>Arāden</settlement>
		<region>Ṣapnā</region>
		<region>ʿAmādīyā</region>
</location>

Note that the <district> element in TEI is defined to be a portion of a city, not a small region surrounding a city, as the term is used by Wilmshurst. Note also that the order of the containing places is from smallest to largest, which implies that the first <region> element is smaller than the second, and contained therein.

Both the <region> and <settlement> elements in this <location> element can have a @ref attribute which points to the Syriaca.org URI for these places. This is useful for indicating relationships between places, and helps quickly disambiguate places of the same name. With the URIs added, this example looks like:

<location type="nested" source="#bibX-1">
		<settlement ref="http://syriaca.org/place/256">Arāden</settlement>
		<region ref="http://syriaca.org/place/783">Ṣapnā</region>
		<region ref="http://syriaca.org/place/703">ʿAmādīyā</region>
	</location>

<event> (optional)

The <event> element is used to indicate events which happened to a place, such as being founded, being destroyed, or anything else. The event can be described using a <p> element, within the <event> element. The date of the event can be indicated by attributes (@when, @notBefore, @notAfter, @from, @to, all of which take arguments in yyyy-mm-dd format, according to the W3C XML Schema Part 2: Datatypes Second Edition). As with other assertions in the place record, the source of this information must be given by including in a @source attribute a pointer to a <bibl> element later in the <place> element.

For example, the flood of the river Daysan which destroyed part of Edessa in 201 CE could be represented by the following <event> element:

<event when="0201" source="#bib78-1">
     <p xml:lang="en">
          Flood of the river
          <placeName ref="http://syriaca.org/place/191">Daiṣan</placeName>
          destroyed part of city.
     </p>
</event>

When specifying the date, @when is a simple date. If the precise date of the event is unknown, its terminus post quem can be represented by @notBefore and its terminus ante quem by @notAfter. Events that took place over a range of dates (e.g. ecclesiastical councils) can have that range specified by @from and @to, representing respectively the beginning and ending dates. For example, we know that the Tigris river shifted its course some time between 79 and 116, so within the <place> for the Tigris river there could be the following <event> element:

<event notBefore="0079" notAfter="0116">
	<p xml:lang="en">Changed course to run between Kokhe and
	Ctesiphon rather than between Kokhe and Seleucia</p>
</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">
		<p xml:lang="en">Site of Ecumenical Council</p>
</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">
	<p xml:lang="en">Renamed Edessa by Seleucus I Nicator.</p>
</event>

Attestations using <event> (optional)

It is possible to record attestations of a place name or confessional affiliation in ways that are susceptible to machine analysis. By “attestation” we mean an occurrence in a primary source of the name form or of the fact of the presence of a certain religion. The <placeName> and <state> elements do not have structures that permit aligning the datable attributes with the cited sources. An attestation is encoded as an <event> with @type “attestation” and @xml:id of the form “attestation{j}-{k}”, where “{j}” is replaced with the SRP place ID # (the final digits of the URI) and “{k}” is replaced with the number of this attestation event in the order they were entered. The attestation <event> includes a @source attribute which points to the <bibl> element encoding the cited work, and a <link> element whose @target attribute includes the @xml:id of the attested <placeName> or <state>.

Any reference to a place name in a primary source is an attestation, even if the primary source cannot be dated exactly. The temporal attributes (@when, @from, @to, @notBefore, and @notAfter) may be used in the <event> element which represents the attestation to indicate the state of knowledge concerning the time of the attestation. The <event> element requires contents. For name attestations, the contents of the <event> element should simply be <p>Attestation of name {placeName} in {Author}, {title-of-work}</p>. For confession attestations, the contents of the <event> element could similarly be <p>Attestation of confession {name} in {Author}, {title-of-work}</p>. Alternately the <p> element could provide more precise indication of what exactly is attested, which we are taking as evidence for a religious community. For example, <p>Attestation of Chalcedonian author in Edessa according to the Chronicle of Edessa.</p> might be linked to the confession “Melkite.” While this content is redundant and not machine-readable, it will facilitate human proofreading.

For a real example, the place Nisibis (place/142) was sometimes known by the name ܨܘܒܐ, which is attested in the “Memra on Ecclesiastical Authors” by Abdisho bar Brikha (d. 1318), on p. 83 of Yosep d-Beth Qelayta’s ed. (http://syriaca.org/bibl/6). Down the road, we may want attestations to link to conceptual works rather than to <bibl>, but for now we cite a <bibl> because that is what we know how to do. Although Abdisho’s work is not dated, it mentions his “Book of the Pearl” which is dated 1603 A.G. (=1291-1292 AD). So the place name itself may be encoded as follows:

<placeName xml:id="name142-5" xml:lang="syr">ܨܘܒܐ</placeName>

The <bibl> element for this edition of Abdisho’s Memra on Ecclesiastical Authors might look like this:

<bibl xml:id="bibl142-6">
	<title xml:lang="syr-Syrn">
	ܟܬܵܒܵܐ ܕܡܸܬܩܪܸܐ ܡܪܓܢܝܬܐ ܕܥܲܠ ܫܪܵܪܵܐ ܕܲܟܪܸܣܛܝܵܢܘܼܬܵܐ</title>
	<ptr target="http://syriaca.org/bibl/6"/>
	<citedRange unit="pp">83</citedRange>
</bibl>

The attestation event could be indicated as follows:

<event type="attestation" xml:id="attestation142-1" notBefore="1291"
			notAfter="1318" source="#bib142-6">
		<p>Attestation of name ܨܘܒܐ in Abdisho bar Brikha, "Memra on
		Ecclesiastical Authors"</p>
                <link target="#name142-5 #attestation142-1"/>
</event>

Note the <link> element within the <event>, which points to the <placeName>.

Duration of place using <state>

In order to permit users to search for places by centuries, each place should have at least one <state> element whose @type attribute has the value “existence”, with temporal attributes (@from, @to) indicating what we know of this place’s period of existence. The value of these attributes needs to be a four-digit year (e.g. 0033 for 33), preceded by a ‘-’ if BCE, and optionally allowing month and day information to be appended in “-mm-dd” format.

<state type="existence" from="0270" to="0694">
</state>

Our schema does not permit @notBefore and @notAfter on the <state> element. In the many cases where the precise beginning or ending dates are not known, the range of possible beginning dates or ending dates must be given within a <precision> element within the <state>. . This precision element will have a @match attribute whose value is either “@from” or “@to” or both (depending on whether the beginning or ending date is uncertain). This precision element can take @notBefore to indicate the terminus post quem and @notAfter to indicate the terminus ante quem of the range of uncertainty. If, as is not uncommon, both the beginning and the end of the place’s existence are uncertain, these uncertainties should be represented by separate <precision> elements. When a <precision> element is used, the value of the @from or @to elements on the parent <state> should be within the range specified by the <precision> element but should be interpreted as imprecise. Note: The dates indicated in the <precision> element(s) are used for search but do not currently display in the HTML.

For example, Kashkar (place/111) is an ancient town in southern Iraq which disappeared sometime after 694 and is documented as abandoned by 1200. We do not know when it ceased to exist other than this terminus ante quem. We also do not know when the town was founded, but it was in existence by 270. This information could be represented as follows (note that the @from and @to values are thus imprecise):

<state type="existence" from="0270" to="0694">
<precision match="@from" notAfter="0270"/>
<precision match="@to" notAfter="1200" notBefore="0694"/>
</state>

The interpretation of this element varies with the type of place. A settlement, (city) quarter, or fortification “exists” when it is inhabited, i.e. occupied by a population, not when its ruins are dug up by archaeologists. A church, monastery, or building “exists” when it is functioning as such, not when its ruins are all that remain, although some re-purposing is permitted. A state or a province “exists” when it is an administrative or governmental unit, while a region “exists” in those periods in which it is considered a culturally recognizable geographic marker. If the period of “existence” continues to the present, it does not need a @to attribute.

For another example, Barsoum says that Mor Behnam Hermitage (place/658) was inhabited until the beginnings of the 17th century, which we have interpreted to mean it was abandoned by 1625:

<state type="existence" to="1625">
	<precision match="@to" notAfter="1625"/>
</state>

Note that in this case we don’t know anything about when it was founded, so no beginning date is represented.

For a third example, Karka d-Ledan (place/656) was a diocese of the Church of the East which is first attested in 410 and last attested in 605. We don’t know when it was created or when it was abolished, but it certainly existed between those two dates, so its existence <state> would look like:

<state type="existence" from="0410" to="0605">
	<precision match="@from" notAfter="0410"/>
	<precision match="@to" notBefore="0605"/>
</state>

As a final example, the Tigris (place/202), as a natural feature, <state type=”existence”/> without any temporal attributes, because it is presumed to have always existed throughout recorded history.

Note: This use of the <precision> element was added to the TEI guidelines by the TEI consortium at the request of Syriaca.org for the specific use cases described above. Additional documentation can be found (as of 2018) at TEI Feature Request #519 and The TEI-L discussion list.

Confessions using <state type=“confession”> (optional)

Some places, such as churches or monasteries, have declared religious identities. Other places, such as cities, may be home to representatives of multiple different religions. Still other places, such as rivers or mountains, have no particular confessional identity in themselves, although they may be venerated particularly by adherents to one or more religions.

To indicate a religious affiliation of a place, Syriaca.org uses the <state> element with a @type attribute whose value is “confession”. The name of the confession must be chosen from the controlled vocabulary of confessions found in http://syriaca.org/documentation/confessions.xml, but because the <state> element cannot directly contain text, the confession name must be wrapped in a <label> element. Thus an indication of the Syrian Orthodox presence in Edessa may be given as follows:

<state type="confession" source="#bib78-1">
	<label>Syrian Orthodox</label>
</state>

In the example above, the source of the information is provided by a reference to the @xml:id of a <bibl> element defined elsewhere in the place. The duration of <state> elements can be indicated using attributes @from and @to, which take dates in yyyy-mm-dd format. Years may be indicated by omitting the “-mm-dd” portion of the string. For a more detailed discussion of the datable attributes, see the discussions of the <state> element of @type=”existence” and the <event> element above. This is particularly useful for indicating when monasteries or churches may have changed hands, but can also indicate the known state of a city or province. So to indicate Syrian Orthodox presence in Edessa from 451 to 1924, this example would look as follows:

<state type="confession" from="0451" to="1924" source="#bib78-1">
	<label>Syrian Orthodox</label>
</state>

Most Middle Eastern cities and regions are not exclusively peopled by adherents to a single religion, so it is important that places may have multiple confessions. Indeed, even churches and monasteries can change hands or, in exceptional cases, be shared between religious groups. Multiple confessions for a particular place, or even disjoint durations of the same confession, are indicated by separate <state> elements, one for each duration of each confession. To add the Muslims and the Latins (during the period of Crusader rule) to the above example of Edessa:

<state type="confession" from="0451" to="1924" source="#bib78-1">
	<label>Syrian Orthodox</label>
</state>
<state type="confession" from="0641" source="#bib78-1">
	<label>Muslim</label>
</state>
<state type="confession" from="1098" to="1144" source="#bib78-1">
	<label>Latin</label>
</state>

In the above example, note that the Muslim presence in Edessa (now Şanlıurfa) continues to the present, so a @from attribute indicates its inception but no @to attribute provides an end-date.

Erroneous Names using <note> (optional)

Certain names in our database are patently erroneous (e.g. ܛܘܪܳܐ ܕܩܰܐܣܒܘܢ for "Mount Qāsiyūn" [place/518] instead of ܛܘܪܳܐ ܕܩܰܐܣܝܘܢ, based on mis-reading an Arabic ba for ya). We need to preserve these names in our data for historical reasons, so that the right place can come up as a search result if someone searches on the basis of the erroneous print resource, but we do not want to assert implicitly or explicitly that this is an “acceptable alternate” form of the name. 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. The <note> also has @type=”deprecation”. The content of the <note> is then a detailed description why this name is considered problematic. 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.

Erroneous and uncertain assertions using <note> (optional)

Sometimes it is necessary to report in a place record information which is either known to be incorrect or which is contested. In these cases it is good to signal this information with a <note> element before the <idno> element(s). The content of the <note> is the description of the problematic assertion, using as non-combative a formulation as possible and avoiding naming living scholars who might be offended. The <note> can have @type=“incerta” if it is reporting scholarly uncertainty or disagreement about an assertion, or @type=”corrigenda” for typographical errors or other equally mechanistic problems which can be easily fixed. The @type=”errata” should only be used for <note> elements if there is a clear and undisputed error whose solution is not obvious. Consider the examples below, drawn from different places:

<note type="incerta">
     GEDSH article identifies its river as the 
     <placeName ref="http://syriaca.org/place/43">Balikh</placeName>,
     but the identification is contested.
</note>
<note type="corrigenda">
     In Dolabani's translation of Barsoum's description ܡܕܝܰܢܬܐ should read ܡܕܺܝܢܬܐ.
</note>
<note type="corrigenda">
     GEDSH Map II displays the location too far to the south, east of 
     <placeName ref="http://syriaca.org/place/91">Ḥama</placeName> 
     rather than west of <placeName ref="http://syriaca.org/place/18">
     Aleppo</placeName>.
</note>
<note type="corrigenda">
     Moosa's English translation of Barsoum's description was incorrectly 
     published under the headword "Samosata," while his description under 
     the headword "Arsamosata" in fact describes the village 
     <placeName ref="http://syriaca.org/place/442">Kaʿbiya</placeName>.
</note>
<note type="errata">
     Barsoum's description erroneously merges the information for this 
     location with that of the other <placeName ref="http://syriaca.org/place/571">
     Mor Bosus</placeName>, which is located between Apamea and Ḥomṣ.
</note>

Disambiguation using <note> (optional)

If the encoder knows that two place entries which otherwise looks similar (for example due to a shared unusual name) are distinct, it is useful to insert a disambiguation note asserting this fact, to prevent the two places from being erroneously merged. It is far easier to prevent a merge of records than to undo one. A <note type=”disambiguation”> may be inserted, preferably containing a link to the URI of the other place which is known to be different. For example:

<note type="disambiguation">
       Not the same place as 
       <placeName ref="http://syriaca.org/place/2532">Baqufa</placeName>.
</note>

If a particular source distinguishes between two places, it is useful to cite it in an @source.

<idno>

Finally, each place record needs one or more <idno> elements to indicate the URIs which refer to this place. Each <idno> element will have a @type attribute with value “URI”, and the first should encapsulate the Syriaca.org URI for the place: http://syriaca.org/place/{\d+}. Other <idno> elements with @type “URI” will encapsulate any Pleiades URI for this place as well as any Wikipedia URL(s) which refer to this place. In particular, if the same place is the topic of separate Wikipedia articles divided by time period, both or all such articles will have their URIs listed here. If desired, a link to a DBpedia resource URI can be encapsulated within an <idno> element of @type “URI”, but care should be exercised only to link to the DBpedia resource URI when the place is the subject of only one Wikipedia article, and when the type of place described by that article is the same as the type of place in our database (it is very common for Wikipedia articles to be about a modern country rather than a historical region, for example, or for village Wikipedia articles found in modern Turkey to be about “a district” rather than about the village itself). If there is any doubt that the DBpedia resource URI and the Syriaca.org URI are speaking of an identical place in all contexts, it is better to omit the DBpedia URI. Although they are not URIs but rather URLs, the URLs for individual keywords in the Comprehensive Bibliography on Syriac Christianity may also be included here (although with each ‘&’ character replaced by “&” in deference to the XML context).

The five URIs of Edessa (one from Syriaca.org, one from Pleiades, two different Wikipedia articles, and on CBSC URL) can be represented as follows:

<idno type="URI">http://syriaca.org/place/78</idno>
<idno type="URI">http://pleiades.stoa.org/places/658457</idno>
<idno type="URI">http://en.wikipedia.org/wiki/Edessa</idno>
<idno type="URI">http://en.wikipedia.org/wiki/Şanlıurfa</idno>
<idno type="URI">
     http://www.csc.org.il/db/browse.aspx?db=SB&amp;sL=E&amp;sK=Edessa&amp;sT=keywords
</idno>

Relationships using <relation>

Relationships between places or between places and other entities can be represented both by RDF triples asserting a relationship given the two URIs, or within TEI using the <relation> element. The <relation> element cannot be contained within a <place> element, but may be contained within a <listPlace> element. Since a TEI document’s <body> cannot directly contain a <place> element, a <listPlace> element will always be used as an intermediary between the <body> and the <place> elements within a document. After the <place> element, a <relation> element may document this place’s relationship with other places or other entities.

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, as follows:

<relation name="share-a-name" mutual="#place-10  http://syriaca.org/place/995"/>

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”:

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

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 value of the @name attribute on the element does not experience inflection to reflect the plural subject, i.e. the multiple values of the @active attribute.

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.

Attribution

This encoding manual was originally written by Thomas A. Carlson. David A. Michelson made revisions and additions. Michelle M. Taylor fully revised the document and encoded it in Markdown. This work is licensed under a Creative Commons Attribution 4.0 Unported License. Copyright Vanderbilt University and the Contributor(s), 2018.