GEOBIB_TEI

element abstract { note? & model.pLike+ }

element author { note* & persName? & persRef* }

Particularly where cataloguing is likely to be based on the content of the header, it is advisable to use a generally recognized name authority file to supply the content for this element. The attributes key or ref may also be used to reference canonical information about the author(s) intended from any appropriate authority, such as a library catalogue or online resource.

In the case of a broadcast, use this element for the name of the company or network responsible for making the broadcast.

Where an author is unknown or unspecified, this element may contain text such as Unknown or Anonymous. When the appropriate TEI modules are in use, it may also contain detailed tagging of the names used for people, organizations or places, in particular where multiple names are given.

element bibl
{
   relatedItem?
 & author?
 & editor?
 & pubPlace?
 & publisher?
 & note?
 & abstract?
 & circulation?
 & editions?
 & genre?
 & illustrations?
 & licenseNote?
 & price?
 & printer?
 & reception?
 & edition?
 & extent?
 & idno?
}

Contains phrase-level elements, together with any combination of elements from the biblPart class

element biblFull { ( titleStmt, extent?, publicationStmt ), sourceDesc* }

element circulation
{
   attribute thisEdition { text }?,
   attribute allEditions { text }?,
   ( note*, text )
}

element date
{
   att.datable.attribute.calendar,
   att.responsibility.attribute.cert,
   ( note* & text? )
}

element edition { att.global.attributes, macro.phraseSeq }

element editions { note*, text }

element editor { attribute cert { text }?, ( note* & text? ) }

A consistent format should be adopted.

Particularly where cataloguing is likely to be based on the content of the header, it is advisable to use generally recognized authority lists for the exact form of personal names.

element extent { attribute cert { text }?, ( note* & text? ) }

element fileDesc { ( titleStmt, extent?, publicationStmt ), sourceDesc+ }

The major source of information for those seeking to create a catalogue entry or bibliographic citation for an electronic file. As such, it provides a title and statements of responsibility together with details of the publication or distribution of the file, of any series to which it belongs, and detailed bibliographic notes for matters not addressed elsewhere in the header. It also contains a full bibliographic description for the source or sources from which the electronic text was derived.

element forename { attribute cert { text }?, ( text? ) }

element genre
{
   attribute type
   {
      "Erinnerungsbericht"
    | "Roman"
    | "Drama"
    | "Tagebuch"
    | "Erzählung"
    | "AutobiographischerBericht"
    | "Gedicht(sammlung)"
    | "Gedicht"
    | "other"
   }?,
   note?
}

element idno
{
   att.global.attribute.rend,
   attribute type { data.enumerated }?,
   ( text | model.gLike | idno )*
}

In the last case, the identifier includes a non-Unicode character which is defined elsewhere by means of a <glyph> or <char> element referenced here as #sym.

idno should be used for labels which identify an object or concept in a formal cataloguing system such as a database or an RDF store, or in a distributed system such as the World Wide Web.

element illustration
{
   attribute type { "cover" | "toc" | "other" },
   ( ref? & model.pLike* & note? & illustrator* )
}

element illustrations { illustration+ & note? }

element illustrator { note* & persRef+ }

element licenseNote { note* & ( text ) }

element listPerson { person+ & note? }

The type attribute may be used to distinguish lists of people of a particular type if convenient.

element listPlace { note? & place+ }

element note { att.responsibility.attribute.cert, ( text? ) }

For this example to be valid, the code MDMH must be defined elsewhere, for example by means of a responsibility statement in the associated TEI Header:

The global n attribute may be used to supply the symbol or number used to mark the note's point of attachment in the source text, as in the following example:

However, if notes are numbered in sequence and their numbering can be reconstructed automatically by processing software, it may well be considered unnecessary to record the note numbers.

element p
{
   att.fragmentable.attributes,
   ( text? & persRef* & placeRef* & note* )
}

element particDesc { listPerson }

This example shows both a very simple person description, and a very detailed one, using some of the more specialized elements from the module for Names and Dates.

May contain a prose description organized as paragraphs, or a structured list of persons and person groups, with an optional formal specification of any relationships amongst them.

element persName { forename & surname }

element person
{
   att.responsibility.attribute.cert,
   attribute xml:id { xsd:ID },
   attribute role { text },
   attribute alt { text }?,
   ( ref & note* & placeRef? )
}

May contain either a prose description organized as paragraphs, or a sequence of more specific demographic elements drawn from the model.personPart class.

element persRef { attribute target { data.pointer }, ( text+ ) }

element place
{
   att.responsibility.attribute.cert,
   attribute xml:id { xsd:ID },
   attribute alt { text }?,
   attribute station { "first" | "last" }?,
   ( ref & timeStamp* & note* )
}

element placeRef { attribute target { anyUri }, ( text+ & timeStamp* ) }

element price { attribute currency { text }, ( note* & text ) }

element printer { note* & text }

element profileDesc { model.profileDescPart* }

Although the content model permits it, it is rarely meaningful to supply multiple occurrences for any of the child elements of profileDesc.

In earlier versions of these Guidelines, it was required that the <creation> element appear first.

element publicationStmt { note? & publisher? & pubPlace? & date? }

Although not enforced by the schemas, it is a requirement for TEI conformance that information about publication place, address, identifier, availability, and date be given in that order, following the name of the publisher, distributor, or authority concerned

element publisher { persRef? & note* & text }

Use the full form of the name by which a company is usually referred to, rather than any abbreviation of it which may appear on a title page

element pubPlace { attribute cert { text }?, ( note? & placeRef+ ) }

element quote
{
   att.global.attributes,
   att.typed.attributes,
   att.source.attributes,
   macro.specialPara
}

If a bibliographic citation is supplied for the source of a quotation, the two may be grouped using the <cit> element.

element reception { note? & model.pLike+ }

element ref
{
   attribute target { text },
   attribute cert { text }?,
   macro.paraContent
}

The target and cRef attributes are mutually exclusive.

element relatedItem
{
   att.global.attribute.rend,
   attribute type { "child" | "parent" }?,
   attribute cert { text }?,
   attribute target { data.pointer }?,
   ( model.biblLike | model.ptrLike )?
}

If the target attribute is used to reference the related bibliographic item, the element should be empty.

element settingDesc { model.pLike+ | ( model.placeLike | listPlace )+ }

May contain a prose description organized as paragraphs, or a series of <setting> elements.

element sourceDesc
{
   model.pLike+ | ( model.biblLike | model.sourceDescPart | model.listLike )+
}

element surname { text? }

element TEI
{
   att.global.attributes,
   attribute version { data.version }?,
   ( teiHeader, ( ( model.resourceLike+, text? ) | text ) )
}

This element is required.

element teiHeader { fileDesc, model.teiHeaderPart* }

One of the few elements unconditionally required in any TEI document.

element text { text }

element timeStamp { att.datable.w3c.attributes, note? }

element title { attribute type { data.enumerated }?, ( text? & note* ) }

The attributes key and ref, inherited from the class att.canonical may be used to indicate the canonical form for the title; the former, by supplying (for example) the identifier of a record in some external library system; the latter by pointing to an XML element somewhere containing the canonical form of the title.

element titleStmt { title+, model.respLike* }

This class defines the set of chunk- and inter-level elements; it is used in many content models, including those for textual divisions.

Note that this element class does not include members of the model.inter class, which can appear either within or between paragraph-level items.

A superset of the naming elements that may appear in datelines, addresses, statements of responsibility, etc.

This class is used in the content model of elements which reference names of people or organizations.

These characteristics of an individual are typically a consequence of their own action or that of others.

This class of elements can occur only within larger elements of the class inter or chunk. In prose, this means these elements can occur within paragraphs, list items, lines of verse, etc.

In providing a ‘regularized’ form, no claim is made that the form in the source text is incorrect; the regularized form is simply that chosen as the main form for purposes of unifying variant forms under a single heading.

When appropriate, values from an established typology should be used. Alternatively a typology may be defined in the associated TEI header. If values are to be taken from a project-specific list, this should be defined using the <valList> element in the project-specific schema description, as described in 23.3.1.4. .

data.certainty = "high" | "medium" | "low" | "unknown"

Certainty may be expressed by one of the predefined symbolic values high, medium, or low. The value unknown should be used in cases where the encoder does not wish to assert an opinion about the matter. For more precise indication, data.probability may be used instead or in addition.

data.code = data.word

It will usually be the case that the item pointed to is to be found somewhere else in the current TEI document, typically in the header, but this is not mandatory.

data.count = xsd:nonNegativeInteger

Only positive integer values (including zero) are permitted

data.duration.iso = token { pattern = "[0-9.,DHMPRSTWYZ/:+\-]+" }

A duration is expressed as a sequence of number-letter pairs, preceded by the letter P; the letter gives the unit and may be Y (year), M (month), D (day), H (hour), M (minute), or S (second), in that order. The numbers are all unsigned integers, except for the last, which may have a decimal component (using either . or , as the decimal point; the latter is preferred). If any number is 0, then that number-letter pair may be omitted. If any of the H (hour), M (minute), or S (second) number-letter pairs are present, then the separator T must precede the first ‘time’ number-letter pair.

For complete details, see ISO 8601 Data elements and interchange formats — Information interchange — Representation of dates and times.

data.duration.w3c = xsd:duration

A duration is expressed as a sequence of number-letter pairs, preceded by the letter P; the letter gives the unit and may be Y (year), M (month), D (day), H (hour), M (minute), or S (second), in that order. The numbers are all unsigned integers, except for the S number, which may have a decimal component (using . as the decimal point). If any number is 0, then that number-letter pair may be omitted. If any of the H (hour), M (minute), or S (second) number-letter pairs are present, then the separator T must precede the first ‘time’ number-letter pair.

For complete details, see the W3C specification.

data.enumerated = data.name

Attributes using this datatype must contain a word which follows the rules defining a legal XML name (see http://www.w3.org/TR/REC-xml/#dt-name): for example they cannot include whitespace or begin with digits.

Typically, the list of documented possibilities will be provided (or exemplified) by a value list in the associated attribute specification, expressed with a <valList> element.

data.language = xsd:language

The values for this attribute are language ‘tags’ as defined in BCP 47. Currently BCP 47 comprises RFC 4646 and RFC 4647; over time, other IETF documents may succeed these as the best current practice.

A ‘language tag’, per BCP 47, is assembled from a sequence of components or subtags separated by the hyphen character (-, U+002D). The tag is made of the following subtags, in the following order. Every subtag except the first is optional. If present, each occurs only once, except the fourth and fifth components (variant and extension), which are repeatable.

language

The IANA-registered code for the language. This is almost always the same as the ISO 639 2-letter language code if there is one. The list of available registered language subtags can be found at http://www.iana.org/assignments/language-subtag-registry. It is recommended that this code be written in lower case.

script

The ISO 15924 code for the script. These codes consist of 4 letters, and it is recommended they be written with an initial capital, the other three letters in lower case. The canonical list of codes is maintained by the Unicode Consortium, and is available at http://unicode.org/iso15924/iso15924-codes.html. The IETF recommends this code be omitted unless it is necessary to make a distinction you need.

region

Either an ISO 3166 country code or a UN M.49 region code that is registered with IANA (not all such codes are registered, e.g. UN codes for economic groupings or codes for countries for which there is already an ISO 3166 2-letter code are not registered). The former consist of 2 letters, and it is recommended they be written in upper case. The list of codes can be found at http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html. The latter consist of 3 digits; the list of codes can be found at http://unstats.un.org/unsd/methods/m49/m49.htm.

variant

An IANA-registered variation. These codes are used to indicate additional, well-recognized variations that define a language or its dialects that are not covered by other available subtags.

extension

An extension has the format of a single letter followed by a hyphen followed by additional subtags. These exist to allow for future extension to BCP 47, but as of this writing no such extensions are in use.

private use

An extension that uses the initial subtag of the single letter x (i.e., starts with x-) has no meaning except as negotiated among the parties involved. These should be used with great care, since they interfere with the interoperability that use of RFC 4646 is intended to promote. In order for a document that makes use of these subtags to be TEI conformant, a corresponding <language> element must be present in the TEI header.

There are two exceptions to the above format. First, there are language tags in the IANA registry that do not match the above syntax, but are present because they have been ‘grandfathered’ from previous specifications.

Second, an entire language tag can consist of only a private use subtag. These tags start with x-, and do not need to follow any further rules established by the IETF and endorsed by these Guidelines. Like all language tags that make use of private use subtags, the language in question must be documented in a corresponding <language> element in the TEI header.

Examples include

sn

Shona

zh-TW

Taiwanese

zh-Hant-HK

Chinese written in traditional script as used in Hong Kong

en-SL

English as spoken in Sierra Leone

pl

Polish

es-MX

Spanish as spoken in Mexico

es-419

Spanish as spoken in Latin America

The W3C Internationalization Activity has published a useful introduction to BCP 47, Language tags in HTML and XML.

data.name = xsd:Name

Attributes using this datatype must contain a single word which follows the rules defining a legal XML name (see http://www.w3.org/TR/REC-xml/#dt-name): for example they cannot include whitespace or begin with digits.

data.numeric =
   xsd:double | token { pattern = "(\-?[\d]+/\-?[\d]+)" } | xsd:decimal

Any numeric value, represented as a decimal number, in floating point format, or as a ratio.

To represent a floating point number, expressed in scientific notation, ‘E notation’, a variant of ‘exponential notation’, may be used. In this format, the value is expressed as two numbers separated by the letter E. The first number, the significand (sometimes called the mantissa) is given in decimal format, while the second is an integer. The value is obtained by multiplying the mantissa by 10 the number of times indicated by the integer. Thus the value represented in decimal notation as 1000.0 might be represented in scientific notation as 10E3.

A value expressed as a ratio is represented by two integer values separated by a solidus (/) character. Thus, the value represented in decimal notation as 0.5 might be represented as a ratio by the string 1/2.

data.outputMeasurement =
   token
   {
      pattern = "[\-+]?\d+(\.\d+)?(%|cm|mm|in|pt|pc|px|em|ex|gd|rem|vw|vh|vm)"
   }

These values map directly onto the values used by XSL-FO and CSS. For definitions of the units see those specifications; at the time of this writing the most complete list is in the CSS3 working draft.

data.pattern = token

data.pointer = xsd:anyURI

The range of syntactically valid values is defined by RFC 3986 Uniform Resource Identifier (URI): Generic Syntax. Note that the values themselves are encoded using RFC 3987 Internationalized Resource Identifiers (IRIs) mapping to URIs. For example, https://secure.wikimedia.org/wikipedia/en/wiki/% is encoded as https://secure.wikimedia.org/wikipedia/en/wiki/%25 while http://موقع.وزارة-الاتصالات.مصر/ is encoded as http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/

data.probability = xsd:double { minInclusive = "0" maxInclusive = "1" }

Probability is expressed as a real number between 0 and 1; 0 representing certainly false and 1 representing certainly true.

data.temporal.iso =
   xsd:date
 | xsd:gYear
 | xsd:gMonth
 | xsd:gDay
 | xsd:gYearMonth
 | xsd:gMonthDay
 | xsd:time
 | xsd:dateTime
 | token { pattern = "[0-9.,DHMPRSTWYZ/:+\-]+" }

If it is likely that the value used is to be compared with another, then a time zone indicator should always be included, and only the dateTime representation should be used.

For all representations for which ISO 8601 describes both a basic and an extended format, these Guidelines recommend use of the extended format.

While ISO 8601 permits the use of both 00:00 and 24:00 to represent midnight, these Guidelines strongly recommend against the use of 24:00.

data.temporal.w3c =
   xsd:date
 | xsd:gYear
 | xsd:gMonth
 | xsd:gDay
 | xsd:gYearMonth
 | xsd:gMonthDay
 | xsd:time
 | xsd:dateTime

If it is likely that the value used is to be compared with another, then a time zone indicator should always be included, and only the dateTime representation should be used.

data.text = string

Attributes using this datatype must contain a single ‘token’ in which whitespace and other punctuation characters are permitted.

data.truthValue = xsd:boolean

The possible values of this datatype are 1 or true, or 0 or false.

This datatype applies only for cases where uncertainty is inappropriate; if the attribute concerned may have a value other than true or false, e.g. unknown, or inapplicable, it should have the extended version of this datatype: data.xTruthValue.

data.version = token { pattern = "[\d]+(\.[\d]+){0,2}" }

The value of this attribute follows the pattern specified by the Unicode consortium for its version number (http://unicode.org/version). A version number contains digits and fullstop characters only. The first number supplied identifies the major version number. A second and third number, for minor and sub-minor version numbers, may also be supplied.