Syriaca.org Documentation
Planned Revisions using <change type="planned"> (optional)
The Body of the Text: <listPlace>
Attestations using <event> (optional)
Duration of place using <state type=”existence”> (optional)
Confessions using <state type="confession"> (optional)
General rules for use of <note> element
Erroneous Names using <note> (optional)
Erroneous and uncertain assertions using <note> (optional)
Disambiguation using <note> (optional)
Relationships using <relation>
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="http://www.tei-c.org/ns/1.0"
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:srophe="https://srophe.app">
<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>
<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>
<p>Languages codes used in this record follow the Syriaca.org guidelines. Language usage documentation available at: <ref target="http://syriaca.org/documentation/isostandards.xml">http://syriaca.org/documentation/isostandards.xml</ref></p>
</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 <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 namespace declaration, 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).
The Syriac Gazetteer is deployed using a customization of the Srophé App (https://srophe.app). The Srophé App includes a few modifications of the TEI schema to create new attributes specific to the scholarly needs of the fields of digital cultural heritage and Syriac Studies. Following the recommendations of section 23.3.2 of the TEI P5 guidelines, these non-TEI attributes are attached to the https://srophe.app namespace in a namespace declaration in the TEI:header. Specifically, this namespaces is declared in the <TEI> root element as an alternate (not default) namespace.
Here is an example:
<TEI
xml:lang="en"
xmlns="http://www.tei-c.org/ns/1.0"
xmlns:srophe="https://srophe.app"
xmlns:syriaca="http://syriaca.org"
xmlns:svg="http://www.w3.org/2000/svg">
<teiHeader>
At present there are three attributes attached to the https://srophe.app namespace. They are:
- @srophe:tags
- @srophe:computed-start
- @srophe:computed-end
This attribute is used to provide additional annotation in cases where the TEI attribute classes were insufficient. @srophe:tags="#syriaca-headword" is used to mark the headword in each place xml file. See examples below.
This attribute is used to provide additional precision on chronological data in cases where the Srophé App's functions require a greater level of precision than available in the historical sources. See See examples below
The namespace declaration also include xmlns:syriaca="http://syriaca.org" and xmlns:svg="http://www.w3.org/2000/svg. These have been declared in anticipation of their future use in The Syriac Gazetteer but these tag sets are not used at present.
Each <fileDesc> element contains (in order) a <titleStmt>, an <editionStmt>, a <publicationStmt>, and a <sourceDesc>.
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 the file for a specific entry.
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 record 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>
The TEI guidelines recommend that the <titleStmt> element also indicate who is responsible for this specific 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 and use <editor> with @role as indicated further below. In addition, 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 creation of some entries of The Syriac Gazetteer were funded by both 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>
The list of funders here refers to the funding of the specific entry, not the entire Syriac Gazetteer.
Our schema for The Syriac Gazetteer does not currently use <principle>. In addition, because the Srophé app uses the <titleStmt> to primarily encode information about the specific entry, information about the general, associate, and technical editors responsible for The Syriac Gazetteer as a whole are encoded in the <seriesStmt> (see below) not in the <titleStmt>.
The creators and contributors for each specific entry in The Syriac Gazetteer are listed in successive <editor> elements, each with a @role attribute and a @ref attribute which points to the @xml:id of the editor within the "editors.xml" document. The name of the creator or contributor is the content of the <editor> element.
Our usage of the term "creator" follows that of the Dublin Core Terms where a creator is "An entity responsible for making the resource." For our purposes the creator is analogous to the "author" of an entry in a print reference work (e.g. the contributor of an encyclopedia article).
The following distinctions can be used in editor/@role for greater nuance in attribution:
- “creator”: the main author responsible for the XML document both in its intellectual content and its XML encoding;
- “contributor”: a person who contributed some data but is not the main person responsible for the document (e.g. less attribution of responsibility than a "creator")
- “content-author”: a person responsible for the intellectual content encoded in this document (but by implication the content-author is not responsible for the XML encoding);
- “code-author”: a person responsible for the creation of the XML encoding in the document based on the intellectual content created by the "content-author".
The distinction between "creator" and "contributor" is useful for giving partial credit to contributors who may have augmented an entry written primarly by someone else.
The distinction between “content-author” and "code-author" is useful in cases where the entry was drafted in a format other than TEI by the "content-author" and then encoded according to our schema by someone other than the "content-author".
Every TEI file must have at either at least one titleStmt/editor/@role="creator" or at least one pair of titleStmt/editor/@role="content author" and titleStmt/editor/@role="code-author". Many entries will have multiple editors of various types.
There may also be duplicates <editor> elements if the same person performed multiple roles.
Accordingly the editors for the place record for Dunaysar (http://syriaca.org/place/401) is as follows:
<editor role="creator" ref="http://syriaca.org/documentation/editors.xml#tcarlson">Thomas A. Carlson</editor>
<editor role="creator" ref="http://syriaca.org/documentation/editors.xml#dmichelson">David A. Michelson</editor>
<editor role="contributor" ref="http://syriaca.org/documentation/editors.xml#lyarbrough">Luke Yarbrough</editor>
In the Srophé App, all names encoded in the path titleStmt/editor/@role="creator" or titleStmt/editor/@role="content-author"` are used by the app to construct the citation for the entry in the section at the bottom of the HTML page: "How to Cite This Entry"
Thus the example above results in the following citation:
Thomas A. Carlson et al., “Dunaysar — ܕܢܝܣܪ ” in The Syriac Gazetteer last modified July 18, 2014, http://syriaca.org/place/401.
In addition, the contents of every titleStmt/editor element is listed (grouped by type) in the subsection: "Authorial and Editorial Responsibility" of the HTML page. In these cases, all four @roles are labels as "entry contributors"
Both the editors and any other parties who are responsible for the creation of this TEI place record are then also identified individually in <respStmt> elements (<resp> stands for "responsibility"). The schema requires the record have at least one <respStmt> (which would describe the contribution of the <editor role="creator"> if there were only one <editor> in the <titleStmt>). Most records will have multiple <respStmt> elements, especially in cases where there were additional contributions made by persons which did not rise to the level of authorship implied by the four available editor/@role values. 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 or the name of the responsible organization in an <orgName> 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 for the entry on Dunaysar might look as follows:
<titleStmt>
<title level="a" xml:lang="en">Dunaysar
— <foreign xml:lang="syr">ܕܢܝܣܪ</foreign>
</title>
<sponsor>Syriaca.org: The Syriac Reference Portal</sponsor>
<funder>The National Endowment for the Humanities</funder>
<funder>The International Balzan Prize Foundation</funder>
<editor role="creator" ref="http://syriaca.org/documentation/editors.xml#tcarlson">Thomas A. Carlson</editor>
<editor role="creator" ref="http://syriaca.org/documentation/editors.xml#dmichelson">David A. Michelson</editor>
<editor role="contributor" ref="http://syriaca.org/documentation/editors.xml#lyarbrough">Luke Yarbrough</editor>
<respStmt>
<resp>Initial Barsoum entry creation by</resp>
<name ref="http://syriaca.org/documentation/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/documentation/editors.xml#tcarlson">Thomas A. Carlson</name>
</respStmt>
<respStmt>
<resp>Syriac description entry by</resp>
<name ref="http://syriaca.org/documentation/editors.xml#raydin">Robert Aydin</name>
</respStmt>
<respStmt>
<resp>Arabic description entry by</resp>
<name ref="http://syriaca.org/documentation/editors.xml#rakhrass">Dayroyo Roger-Youssef Akhrass</name>
</respStmt>
<respStmt>
<resp>Citation of al-Dunaysarī's Kitāb Taʾrīkh Dunaysar provided by</resp>
<name ref="http://syriaca.org/documentation/editors.xml#lyarbrough">Luke Yarbrough</name>
</respStmt>
</titleStmt>
</titleStmt>
In the HTML view of the record, the contents of the <respStmt> elements are listed in the subsection: "Additional Credit". Because the <respStmt> elements offer a very flexible prose form for attribution, encoders are encouraged to use it extensively to give detailed credit for each record.
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>
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 type="license">used under a Creative Commons Attribution license <ref target="http://creativecommons.org/licenses/by/3.0/"/></note>
</note>
</p>
</license>
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>
<license target="http://creativecommons.org/licenses/by/3.0/">
<p>Distributed under a Creative Commons
Attribution 3.0 Unported License.</p>
</license>
</availability>
<date>2014-01-14-05:00</date>
</publicationStmt>
The <seriesStmt> element in the <fileDesc> encodes the title and editor information for The Syriac Gazetteer as a whole (as opposed to the <titleStmt> which encodes information about the individual entry). The <seriesStmt> must contain a <title> element with an attribute @level with value "s" to indicate that it refers to the whole series of records (e.g. The Syriac Gazetteer).
The <seriesStmt> element also encodes the general editors for The Syriac Gazetteer in successive <editor> elements, each with a @role attribute value and a @ref attribute which points to the @xml:id of the editor within the "editors.xml" document. The name of the editor is the content of the <editor> element. Note: These editors may be authors of individual entries, in which case they would also be separately credited in the <titleStmt> (titleStmt/editor/@role="creator").
Our schema defines the following types of general editors:
-
General Editor (
editor/@role="general"): One or more editors collectively responsible for all of the intellectual content of The Syriac Gazetteer. These editors engage in the review, revision, and approval of all entries. -
Past-General Editor (
editor/@role="past-general"): Same as the General Editors above, but for a fixed (and now completed) term of time which must be indicated with a child element of<date> -
Associate Editor (
editor/@role="associate"): An editor who assisted with reviewing or revising portions of the The Syriac Gazetteer but who is not responsible for the whole publication. (Note: At present The Syriac Gazetteer has not Associate Editors). -
Past-Associate Editor (
editor/@role="past-associate") Same as the Associate Editors above, but for a fixed (and now completed) term of time which must be indicated with a child element of<date> -
Technical Editor (
editor/@role="technical"): An editor who created or assisted in the creation of the technical design of the The Syriac Gazetteer or the curation of its data in digital formats. -
Past-Technical Editor (
editor/@role="past-technical") Same as the Technical Editors above, but for a fixed (and now completed) term of time which must be indicated with a child element of<date>
As is the case with titleStmt/editor, the contents of the seriesStmt/editor (excluding past-editors) is also included in the citation constructed in the HTML in the section "How to Cite This Entry". All editors, including past-editors, are also listed with dates when relevant in the subsection "Authorial and Editorial Responsibility", where they are grouped by @role.
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>
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 @srophe:tags attribute. Those sorts of details are encoded here.
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 has been created following the Syriaca.org editorial guidelines. Documentation is available at: <ref target="http://syriaca.org/documentation">http://syriaca.org/documentation</ref>. <title>The Syriac Gazetteer</title> was encoded using both the general editorial guidelines for all publications of Syriaca.org and an encoding schema specific to <title>The Syriac Gazetteer</title>.</p>
<p>Approximate dates described in terms of centuries or partial centuries have been interpreted into quantitative values as documented in the Syriaca.org guidelines for normalization of dates. See <ref target="http://syriaca.org/documentation/dates.html">Syriaca.org Guidelines for Approximate Dates</ref>.</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). While it is possible to indicate a source for this date, this date is usually based on the estimate of the editors and provided as an aid to searching. As a practice, attested dates for a place based on historical sources have instead been encoded more precisely using <gi>event</gi> of @type="attestation". Natural features which have always existed have no date on the <gi>state</gi> element of @type="existence" since they are are presumed to have always existed throughout recorded history.</p>
<p>In some cases, maps from print publications have been used as the basis for coordinate data in <title>The Syriac Gazetteer</title>. In two instances, the editors of such print maps provided the digital coordinate data used to prepare the print maps. Specifically, coordinates which are attributed to <title>The Gorgias Encyclopedic Dictionary of the Syriac Heritage</title> (<ref target="http://syriaca.org/bibl/1">http://syriaca.org/bibl/1</ref>) or to <title>The Syriac World</title> (<ref target="http://syriaca.org/bibl/PUTG99V4">http://syriaca.org/bibl/PUTG99V4</ref>) were extracted from the KML files used to create the print maps for those volumes. Because only the print maps were published, the citation for these coordinates refers to the print source. The editors of the <title>The Syriac Gazetteer</title> are grateful to the editors of <title>The Gorgias Encyclopedic Dictionary of the Syriac Heritage</title> and <title>The Syriac World</title> for providing these coordinate files.</p>
<p>The editors have silently normalized data from other sources in some cases. The primary instances are listed below.</p>
<p>The capitalization of names from <title>The Gorgias Encyclopedic Dictionary of the Syriac Heritage</title> (<ref target="http://syriaca.org/bibl/1">http://syriaca.org/bibl/1</ref>) was normalized silently (i.e. names in ALL-CAPS were replaced by Proper-noun capitalization).</p>
<p>The unchanging parts of alternate names from the editions and translations of Barsoum, <title>The Scattered Pearls: A History of Syriac Literature and Sciences</title> (<ref target="http://syriaca.org/bibl/2">http://syriaca.org/bibl/2</ref>, <ref target="http://syriaca.org/bibl/3">http://syriaca.org/bibl/3</ref>, or <ref target="http://syriaca.org/bibl/4">http://syriaca.org/bibl/4</ref>) have been supplied silently.</p>
<p>Names from the English translation of Barsoum, <title>The Scattered Pearls: A History of Syriac Literature and Sciences</title> (<ref target="http://syriaca.org/bibl/4">http://syriaca.org/bibl/4</ref>) were silently transformed into sentence word order rather than the headword alphabetization used by Barsoum. Commas were silently removed.</p>
</editorialDecl>
...
</encodingDesc>
The class declaration contains one or more taxonomies defining any classificatory codes used elsewhere in the text. There are various @srophe:tags values 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>
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. The <revisionDesc> should have a @status which indicates the publication stage of the file. Possible values for this attribute include: “draft,” “incomplete,” “published,” and “underReview”. 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/documentation/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/documentation/editors.xml#ngibson"
n="1.1">
ADDED: Pleiades coordinates</change>
<change when="2013-04-01"
who="http://syriaca.org/documentation/editors.xml#dmichelson">
FIXED: Ufra to Urfa</change>
<change when="2013-03-16" who="http://syriaca.org/documentation/editors.xml#tcarlson"
n="1.0">
ADDED: teiHeader/revisionDesc</change>
<change when="2013-03-15" who="http://syriaca.org/documentation/editors.xml#tcarlson">
ADDED: teiHeader</change>
<change when="2013-03-01" who="http://syriaca.org/documentation/editors.xml#tcarlson"
n="0.1">
CREATED: place</change>
</revisionDesc>
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.
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 the controlled vocabulary of place types maintained 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:
- a series of
<placeName>elements - one or more
<desc>description elements - zero or more
<location>elements - zero or more
<eventelements - zero or more
<state>elements - zero or more
<note>elements - one or more
<idno>elements - one or more
<bibl>elements
Each category of elements will be described in document order of occurance with the exception of the <bibl> elements. Our manual will discuss the use of <bibl> elements first because of its central place in the way that the Srophé app facilitates the citation of bibliographic references. <bibl> elements are placed at the end of each record as the TEI equivalent of a series of bibliographic endnotes. References to these citations can be made from any other element in the XML file, effectively creating a universal format for citations throughout the document.
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 record for the bibliographic item in the separate Syriaca.org bibliography module. 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 The Gorgias Encyclopedic Dictionary of the Syriac Heritage, it might look like the following:
<bibl xml:id="bib78-1">
<ptr target="http://syriaca.org/bibl/1"/>
</bibl>
There is one exception to the rule that each <bibl> element at the end of the document must have a child <ptr> element. At present the Srophé App does not have a separate module for the citation of manuscripts. This feature is planned for future development. Until then, the schema permits the omission of a <ptr> element when the refernce is directly to a manuscript rather than to a printed source. These cases must mark the <bibl> element with @type="syriaca:Manuscript"
If a page number is included in the citation, it is contained in a <citedRange> element whose mandatory @unit attribute has the value "p". 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="p">556</citedRange>
</bibl>
Allowed values for @unit in a <citedRange> are "col" (for column), "entry", "fol" (for folio), "line", "map", "part", "p" (for page), "section", or "vol" (for volume). These values remain the same even if the cited range is plural, thus <citedRange unit="p">556</citedRange> and 556-558. When multiple page numbers are cited, they should be entered in full and never be abbreviated (thus 556-558 not 556-8).
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="p">138-139</citedRange>
</bibl>
<bibl xml:id="bib78-3">
<title xml:lang="syr">ܒܪ̈ܘܠܐ ܒܕܝܪ̈ܐ ܕܥܠ ܡܪܕܘܬ ܝܘܠܦܢ̈ܐ ܣܘܪ̈ܝܝܐ ܗܕܝܪ̈ܐ
</title>
<ptr target="http://syriaca.org/bibl/3"/>
<citedRange unit="p">556</citedRange>
</bibl>
Alternately, though The Syriac Gazetteer does currently not employ this option, extended footnotes with multiple citations can be created by wrapping multiple <bibl> elements within a <listBibl> element. In this case, the <listBibl> is marked with the @xml:id attribute instead, since the footnote is generated from the whole list of <bibl> elements within.
Such a multi-reference footnote can be encoded as follows:
<listBibl xml:id="bib78-4">
<bibl>...<ptr target=“http://syriaca.org/bibl/3”/></bibl>
<bibl>...<ptr target=“http://syriaca.org/bibl/4”/></bibl>
</listBibl>
The resulting footnote will format each citation contained in the <bibl> inside the <listBibl> as a chain of citations separated by semicolons, but otherwise use the same template for how to render <bibl> elements into prose.
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.
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".
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>
Using a feature native to the Srophé App, Syriaca.org designates one English name and (where available) one Syriac name as preferred name forms for use in headers, alphabetizing search result lists, etc. These Syriaca.org preferred name forms are indicated by the use of a non-TEI attribute on the <placeName> element whose value is "#syriaca-headword". This attribute is attached to the namespace https://srophe.app associated with the Srophé App.
Here is an example where "Edessa" is the Syriaca.org English headword for a place:
<placeName xml:id="name78-1" xml:lang="en"
syriaca-tags="#syriaca-headword"
source="#bib78-1 #bib78-2 #bib78-5 #bib78-6">
Edessa
</placeName>
To facilitate sorting and browsing, the srophe:tags="#syriaca-headword" can be used only once per language (as indicated in the @xml:lang value). Accordingly, each record must have one and only one <placeName> element with the combination of @srophe:tags="#syriaca-headword" and @xml:lang="en". The use of an English headword is required, but the use of Syriac headword is only recommended because a Syriac name form may not exist for all entities (for example for the place Nashville, TN). In addition to English and Syriac, the @srophe:tags="#syriaca-headword" may also be used to indicate preferred forms in other languages such as Arabic or French at the discretion of editors.
As a rule, data in Syriaca.org records should be derived from a prior source and cited using a pointed in @source connected to a <bibl> element (see above). In some cases, however, data may be added to the records without any other source than the interpretation of the Syriaca.org editors and contributors. These additions are marked with @resp.
For example, 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>
Similarly, the @reps attribute can be used with <location> in instances were the location information has been collected by a Syriaca.org contributor but is not attested in print.
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.
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.
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 <desc> element with the @xml:id attribute set to “abstract” followed by the Syriaca.org id # (i.e. the final digits in the URI), a hyphen, and a unique numeric value. Visualized differently, the abstract xml:id is constructed as “{abstract}{numeric value portion of the URI}-{a unique numeric value}”. It should also have an @xml:lang attribute set to the language of this abstract. The element will look as follows:
<desc type="abstract" xml:id="abstract78-1" xml:lang="en">
If the abstract comes from a print source, then it should be encapsulated by a <quote> 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="p">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.
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. The schema currently permits three @types of <location>.
- location/@type="gps" with
<geo>
This type is used for GPS coordinate data.
- location/@type="relative" with
<measure>and<offset>
This type is used for relative or prose location data.
- location/@type="nested" with various TEI elements for Geo-political Place Names
This type is used for contextual location data, e.g. to describe a location in terms of larger geographic or political entities.
If the record has data from multiple sources, a separate <location> element should be created for each data type from each source. Thus it is possible for a record to have multiple <location> elements which reference the same source and also to have multiple <location> elements of the same @type ("gps", "relative", "nested") if each represents a different source or even a different piece of data in a source.
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>
If a record represents a place type that is not definable by a single GPS coordinate set, such as ‘region’, then associated GPS data should be encoded in a <location> element and marked as @subtype="representative". For example, Pleiades will often include a ‘representative point’, usually the centroid of some more expansive geometry, with places of @type="region". The coordinates for Beth Aramaye, taken from Pleaides, would therefore be represented as follows:
<location type="gps" subtype="representative" source="#bib717-2">
<geo>32.5 44.5</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". Alternate co-ordinates should be marked as @subtype = "alternate". Only the "preferred" location will be displayed on map views. This is required whenever more than one <location> element has coordinate data. If the location is also a representative point, as described above, replace @subtype="preferred" with @subtype="representative". Do not change the <location> elements of @subtype="alternate" as their representative nature is implied by the ‘preferred/representative’ <location> element.
Similarly, if there are different GPS coordinates based on different sources, these should be put in different <location> elements each with a different @source attribute, rather than in multiple <geo> elements within a single <location>
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="p">553</citedRange>
</bibl>
In the TEI P5 Guidelines, section 13.2.3.1 provides a hierarchy of generic element names for Geo-political Place Names which can be used to describe a location in terms of its context in "geo-political or administrative units". The Syriac Gazetteer adds an @type="nested" annotation to the location when using these element names to indicate contextual relationships.
For example, in data derived from geographic index of David Wilmshurst’s The Ecclesiastical Organisation of the Church of the East, 1318-1913 a place is often indicated in the context of larger places which contain it. Thus "Beni Shmūni, Arāden, Ṣapnā district, ʿAmādīyā region, 138" in the index of churches indicates Arāden is the city containing this church of Beni Shmūni, Ṣapnā district is the name of the smaller region containing that city, and ʿAmādīyā region is 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 the Syriaca.org encoding guidelines require the order of the containing places to proceed from smallest to largest in document order, i.e. "arranged in ascending sequence according to their size or administrative importance" (as recommended in the TEI guidelines), which implies that the first <region> element (<region>Ṣapnā</region>)is smaller than the second, and contained therein. The order of usage should be:
<district>
<settlement>
<region>
<country>
<bloc>
These child elements in TEI:location/@type="nested" can take a @ref attribute which points to the Syriaca.org URI for the contextually related places. This is useful for indicating relationships between places, and helps quickly disambiguate places of the same name. With the URIs added, the example above 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>
In addition, it is possible to add to the textnode a label, if this will assist the user:
<location type="nested" source="#bibX-1">
<settlement ref="http://syriaca.org/place/256">Arāden settlement</settlement>
<region ref="http://syriaca.org/place/783">Ṣapnā district</region>
<region ref="http://syriaca.org/place/703">ʿAmādīyā region</region>
</location>
It should be noted that the element names provided by the TEI guidelines may not always match the geo-political terminology as used in the field of Syriac Studies and thus some translation is required for encoding into TEI XML. For example, there is a <district> element in TEI, but this element is defined by the TEI guidelines as a portion of a city, i.e. contained by a settlement. In the example above from David Wilmshurst, the term "district" is used by Wilmshurst to refer to a sub-region surrounding a city. Accordingly, Wilmshurst's "district" has been encoded as a <region> in TEI but labelled with the technical term used in the original source.
Similarly, in some cases the TEI's political terminology is perhaps too narrow for pre-modern history. For example, the TEI only provides <country> and <bloc> as entities larger than a region. In this case, the Syriac Gazetteer has chosen to view the TEI element <country> as equivalent to the "sovereign state" entity as defined by the Getty Art and Architecture Thesaurus and the "state (polity)" place type as defined in Pleiades: A Gazetteer of Past Places, even if the term "country" is an anachronistic label for the Roman Empire (http://syriaca.org/place/166). A full list of the place type definitions used by Syriac.org is available here.
Finally, when the nested geographic relationship has temporal limits, then any of the TEI att.datable attribute classes (@when, @notBefore, etc.) can be used on the <location> element to indicate the dates of the relationship. For example the encoding below indicates that the settlement of Edessa was part of the Roman province of Osrhoene and the Roman Empire but only until 641 C.E.
<location type="nested" source="#bib78-1" to="0641">
<region ref="http://syriaca.org/place/145">Osrhoene</region>
<country ref="http://syriaca.org/place/166">Roman Empire</country>
</location>
Note that dates should only be marked as attributes on the <location> element not in the child elements (<region>, <country>, etc.). In the event that contextual relationships have different end or start dates, a separate <location> element should be used to encode each different date, even if the source for this data is the same in each <location>.
The <event> element is used to indicate events which happened to a place, such as being founded, being destroyed, or anything else. To distinguish the use of event for historical events from the same event element for attestations (see below) the event must take @type of "other". 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 values in the yyyy-mm-dd format of the ISO 8601 date and time format standards, with the extra adaptations for the year zero and dates before the common era published by the W3C in XML Schema Part 2: Datatypes Second Edition). Syriaca.org maintains an additional documentation page for Dating Conventions which should also be consulted by users and editors of The Syriac Gazetteer.
As with other assertions in the place record, the source of date 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 type="other" 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 type="other" 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 type="other" 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 type="other" when="-0304" source="#bib78-1">
<p xml:lang="en">Renamed Edessa by Seleucus I Nicator.</p>
</event>
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="bib142-6">
<title xml:lang="syr-Syrn">
ܟܬܵܒܵܐ ܕܡܸܬܩܪܸܐ ܡܪܓܢܝܬܐ ܕܥܲܠ ܫܪܵܪܵܐ ܕܲܟܪܸܣܛܝܵܢܘܼܬܵܐ</title>
<ptr target="http://syriaca.org/bibl/6"/>
<citedRange unit="p">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 <foreign xml:lang="syr">ܨܘܒܐ</foreign> in Abdisho bar Brikha, <title level="m">Memra on Ecclesiastical Authors</title></p>
<link target="#name142-5 #attestation142-1"/>
</event>
<event type="attestation" xml:id="attestation142-2" notBefore="1224" notAfter="1228" source="#bib142-8" syriaca-computed-start="1224-01-01" syriaca-computed-end="1228-01-01">
<p xml:lang="en">Attestation of name <foreign xml:lang="ar">نَصِيبين</foreign> in the <title xml:lang="en" level="m">Muʿjam al-buldān</title> of <persName>Yāqūt al-Ḥamawī</persName>.</p>
<link target="#name142-9 #attestation142-2"/>
</event>
Note the <link> element within the <event>, which points to the <placeName>.
In order to permit users to search for places by centuries, each place may have one or more <state> elements 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. While it is possible to indicate a source for this date, this date is usually based on the estimate of the editors and provided as an aid to searching. As a practice, attested dates for a place based on historical sources have instead been encoded more precisely using <event type="attestation">.
<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" (depending on whether the beginning or ending date of the existence 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 the use of two 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" notBefore="0694" notAfter="1200"/>
</state>
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.
The interpretation of state/@type="existence" 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 another 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.
As evident from the examples above, ancient and medieval chronological data can often be imprecise in terms of dates. It is quite common for an historical source to indicate only the year of an event rather than a specific month or day. The Srophé App has several tools and functions for sorting data by date, such as a timeline function. For these functions to calculate a date range, however, it is necessary to provide an ISO month and day even when one is not known. Accordingly, Syriaca.org has established a two-part encoding process to both maintain the original imprecision of the source (i.e no date, no month) and to also provide the Srophé App with precise dates that can be used for calculations. The encoding policy is as follows. All dates should be encoded with only the precision available from the historical sources following the patterns above. After this data has been entered but before finalization of the xml file, a data maintenance script is run on the data to create a second set of date encodings uinsg the @srophe:computed-start and @srophe:computed-end attributes attached to the https://srophe.app namespace. These encodings are always machine-generated and updated and should not be encoded by hand. The result based on the example above from Karka d-Ledan (place/656) is:
<state type="existence" from="0410" to="0605" srophe:computed-end="0605-01-01" srophe:computed-start="0410-01-01">
<precision match="@from" notAfter="0410" srophe:computed-end="0410-01-01"/>
<precision match="@to" notBefore="0605" srophe:computed-start="0605-01-01"/>
</state>
The values provided in @srophe:computed-start and @srophe:computed-end are an approximation for the use of the Srophé App only. These dates will not appear in the HTML view of the record, nor should human users consider them to be anything other than heuristic values to permit calculations. The dates are intentionally set to January 1 (the earliest possible date possible) because the actual date is unknown. In the scenario in which a specificmonth was specified in the source but not a day, the first of that month is set as the computed date used in @srophe:computed-start and @srophe:computed-end.
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.
Like with duration of place in <state type=”existence”>, a precision element can be used to indicate when the precise beginning or ending dates of the confession are not known. This precision element will have a @match attribute whose value is either “@from” or “@to” (depending on whether the beginning or ending date is uncertain), and will use @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 elements. When a element is used, the value of the @from or @to elements on the parent should be within the range specified by the element, but are not otherwise meaningful.
All <note> elements, including those employed for the next three sections, must have an @xml:lang value. This facilitates the display of the notes by language in the Srophé application.
All <note> element must have an @type value. The current list of allowed values for note/@type are:
- "corrigenda"
- "deprecation"
- "disambiguation"
- "errata"
- "incerta"
- "license"
The Srophé application displays the note/@type value as a label on the note in most cases. For example, note/@type="deprecation" will be labelled as "Deprecation" in the HTML view. In the case of note/@type="license" in the <teiHeader>, the @type label is not displayed.
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 letter 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 even if someone searches on the basis of the erroneous print resource or now deprecated name, 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 a @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>, an @target attribute whose value is the @xml:id values for the deprecated <placeName> is included in the <note> separated by whitespace if there are links to multiple names for the same reason in the note. TEI Guidelines do not allow <note> elements before <desc>, <location>, <event>, or <state> elements, so the <note> indicating the deprecation should occur immediately before the <idno> section.
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" target="#name993-3 #name993-4">Dolabani transcribed the name from Arabic rather than presenting a native Syriac form.</note>
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>
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.
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&sL=E&sK=Edessa&sT=keywords
</idno>
While the <place> element contains all the data defining, describing, and disambiguating the place, the <listPlace> element can also contain stand-off markup related to the conceptual place in a <listRelation> element which describes relationships between multiple places or between the primary place described in the TEI document and other Syriaca.org entities (e.g. persons).
There is only one <listRelation> element per xml file and it should contain all the <relation> elements. The <relation> should never occur within the <place> element.
The <relation> element is generic, so Syriaca.org relies on the use of controlled vocabularies from outside the TEI to describe the relationship. The <relation> element has a mandatory @name attribute whose value should define relationship (it can be thought of as the “verb” in the sentence). The @name attribute value cannot contain any spaces, so Syriaca.org maintains a standardized list of allowed values. Currently the only allowed relationships “share-a-name” or "see-also".
- “share-a-name” describes two or more places which share an identical or similar name.
- "see-also" identifies a general or otherwise unspecificed relationship between two or more places. This relationship frequently reflects data derived from the indices of printed maps or gazetteers.
Future relationship names can be proposed to the editors as needed.
For example, the settlement Abnaye (http://syriaca.org/place/882) shares a name with Abnaye the diocese (http://syriaca.org/place/2276), so in the TEI for the settlement, the <relation> element appears as follows:
<relation name="share-a-name" mutual="http://syriaca.org/place/882 http://syriaca.org/place/2276"/>
If the relationship is mutual, as in the example above, then pointers to the entities among which this relationship holds are given as space separated values in a @mutual attribute. Currently the only relationships in use are “share-a-name” and "see-also" which are considered mutual relations. In future development of the mark up, 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. To facilitate the serialization of linked data triples from the TEI file, these pointers must be Syriaca.org URIs for the entities in question.
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.
Although it is possible to express nested or containing relationships between places in the <relation> element, as a policy decision, Syriaca.org prefers to document such relationships in <location type="nested"> element instead. See <location>.
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 strongly prefers to document such relationships in the TEI document for the person record instead.
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 in 2019. This work is licensed under a Creative Commons Attribution 4.0 Unported License. Copyright Vanderbilt University and the Contributor(s), 2020.