<!-- $Id: p2sh.odd,v 1.10 1998/02/01 17:38:08 tei Exp $ -->
<!--*
    * $Log: p2sh.odd,v $
    * Revision 1.10  1998/02/01 17:38:08  tei
    * fix Log keyword,
    * normalize SGML
    * replace system identifiers with public identifiers.
    * -->
<!-- Revisions:                                               -->
<!-- 94-03-29 : MSM : change CITY to pubPlace                 -->
<!-- 93-09-16 : MSM : validated (and fixed) examples          -->
<!-- 16 Sep : LB minor typos fixed -->
<!-- 93-09-15 : MSM : second pass started, completed          -->
<!-- 93-09-10 : MSM : finish first pass at revisions          -->
<!-- 93-09-10 : MSM : first cut at revisions                  -->
<!-- 93-06-05 : MSM : correct typo in eg                      -->
<!-- 93-06-05 : MSM : cap DTD                                 -->
<!-- 93-06-03 : MSM : change dtdfrag, reformat for legibility -->
<!-- Date: Thu, 27 May 93 18:33:11 BST -->
<!-- Lou, I tried my best with the biblStruct elelent, and    -->
<!-- I added some notes in the MARC discussion.   Has the     -->
<!-- Chapter 5 (the Header) been revised.  Section 5.2.7      -->
<!-- still contains <citnStruct> in the example, as does      -->
<!-- the content model.  Let me know if there's more to do.   -->


<!-- Date:, Thu, 24 May 93 22:40:01 BST -->
<!-- From: Richard Giordano <rich@computer-science.manchester.ac.uk> -->


<div1 id="SH" n="24"><head>The Independent Header</head>

<!--  < p >  If you plan to send headers as independent       -->
<!-- documents to remote locations, then you should follow    -->
<!-- the recommendations outlined in this chapter as well     -->
<!-- as Chapter  < xref target=HD > .                         -->

<p>Many libraries, text repositories, research sites and related
institutions collect bibliographic and documentary information about
machine readable texts without necessarily collecting the texts
themselves.  Such institutions may thus want access to the header of a
TEI document without its attached text in order to build catalogues,
indexes and databases that can be used by people to locate relevant
texts at remote locations, obtain full documentation about those texts,
and learn how to obtain them.  This chapter of the Guidelines describes
a set of practices by which the headers of TEI documents can be
extracted from those documents and exchanged as freestanding independent
TEI documents.  Headers exchanged independently of the documents they
describe are called <term>independent headers</term>.

<!--
<note place=foot>The responsibility for this chapter was borne by -->
<!-- the Working Committee for Text Documentation, whose members are -->
<!-- listed in the front matter.  The chapter was drafted by Richard -->
<!--     Giordano.</note> --></p>

<p>This chapter outlines practices recommended for encoders (especially
those responsible for the documentation of text) when creating
independent headers to be distributed, and specifies the set of
recommended elements that should be included in the independent header.
Of interest to librarian cataloguers who may receive independent headers
from remote sites, it also discusses the relationship between the
elements of TEI headers and MARC tags, in order to facilitate the
cataloguing of these headers or the loading of independent headers into
local MARC-based bibliographic databases.   This chapter does
<emph>not</emph> describe how to create a header.  Guidance on the
creation of headers and descriptions of each element in the header can
be found in chapter <ptr target="HD">.</p>


<div2 id="SHdef"><head>Definition and Principles for Encoders</head>

<p>An <term>independent header</term> is a header extracted from a TEI
text that can be exchanged as an independent document between libraries,
archives, collections, projects, and individuals.  The file description
of the independent header (enclosed by the <gi>fileDesc</gi> element)
can be used to generate bibliographic records.  The profile description,
encoding description, and revision history (encoded by the
<gi>profileDesc</gi>, <gi>encodingDesc</gi>, and <gi>revisionDesc</gi>
elements) can form part of a bibliographic description or, more
appropriately, be used as an attached <socalled>codebook</socalled> for
full documentation of the analysis of the text and how it was encoded.
Thus, the independent header can serve as the primary means by which
libraries, archives, related repositories, research projects, and
individual researchers can obtain bibliographic, descriptive, and full
documentary information on machine-readable texts that reside in remote
locations.</p>

<p>The structure of an independent header is exactly the same as that of
a <gi>teiHeader</gi> attached to a document, and can therefore be
validated using the same document type definition (DTD).  In practice,
this means that a <gi>teiHeader</gi> and its DTD can be extracted from a
TEI document and shipped to a receiving institution with little or no
change.  However, some fields that are listed as <q>optional</q> in the
header are listed as <q>recommended</q> for the independent header.  For
this reason, this chapter should be consulted in connection with any
plan to send headers as independent documents.</p>

<p>When deciding which information to include in the independent header,
and the format or structure of that information, the following should be
kept in mind:</p>

<p>The independent header should provide full bibliographic information
on the encoded text, its source, where the text can be located, and any
restrictions governing its use.</p>

<p>The independent header should contain useful information about the
encoding of the text itself.  In this regard, it is highly recommended
that the encoding description be as complete as possible.  The
Guidelines do not require that the encoding description be included in
the header (since some simple transcriptions of small items may not
require it), but in practice the use of a header without an encoding
description would be severely limited.</p>

<p>The independent header should be amenable to automatic processing,
particularly for loading into databases and for the creation of
publications, indexes, and finding aids, without undue editorial
intervention on the part of the receiving institution.  For this reason,
two recommendations are made regarding the format or structure of the
header:  first, where there is a choice between a prose content model
and one that contains a formal series of specialized elements,
<emph>wherever possible and appropriate the specialized elements should
be preferred to unstructured prose</emph>.  For instance, the source
description can contain either a free-prose citation (tagged
<gi>bibl</gi> or even <gi>p</gi>) or a <gi>biblStruct</gi> element,
which provides a more rigorous structure for the bibliographic
information (see examples in section <ptr target="CObi">).  The more
structured <gi>biblStruct</gi> element is more suitable for automatic
processing, and is therefore recommended over the less structured
alternatives whenever the header is to be exchanged as an independent
header.  Second, with respect to corpora, information about each of the
texts within a corpus should be included in the overall corpus-level
<gi>teiHeader</gi>.  That is, source information, editorial practices,
encoding descriptions, and the like should be included in the relevant
sections of the corpus <gi>teiHeader</gi>, with pointers to them from
the headers of the individual texts included in the corpus.  There are
three reasons for this recommendation:  first, the corpus-level header
will contain the full array of bibliographic and documentary information
for each of the texts in a corpus, and thus be of great benefit to
remote users, who may have access only to the independent header;
second, such a layout is easier for the coder to maintain than searching
for information throughout a text; and third, generally speaking, this
practice results in greater overall consistency, especially with respect
to bibliographic citations.</p></div2>

<div2 id="SHrr"><head>Required and Recommended Tags</head>

<p>The richness and size of the header reflect the diversity of uses to
which electronic texts conforming to these Guidelines will be put.  It
is not intended, however, that all of the elements recommended in this
chapter be present in every header.  As described in section <ptr
target="HD7">, the TEI header allows for the provision of a very large
amount of information concerning the text itself, its source, encodings,
and revisions as well as detailed descriptive information that can be
used by researchers in analysing the text.  The amount of encoding will
depend on the nature and intended use of the text.  At one extreme, an
encoder may expect that the header will only provide bibliographic
information about the text adequate to local needs.  At the other,
wishing to ensure that their texts can be used for the widest range of
applications, encoders will want to document as explicitly as possible
both bibliographic and descriptive information in such a way that no
prior or ancillary knowledge about the text is needed in order to
process it.  The header, in the latter case, will be very full,
approximating the kind of documentation often supplied in the form of a
manual.  Most texts will lie somewhere between these extremes; textual
corpora in particular will tend toward the latter extreme.</p>

<p>The following is a list of the components of the header, in the order
in which they are presented in chapter <ptr target="HD">, together with
an indication of their importance in constructing an independent header.

<list type="bullets">
<item><gi>fileDesc</gi> required.  Some subelements are required,
others optional or recommended:
<list>
<item><gi>titleStmt</gi> required; subelements are required or
optional:
<list>
<item><gi>title</gi> required</item>
<item><gi>author</gi> required, if known</item>
<item><gi>sponsor</gi> optional</item>
<item><gi>funder</gi> optional</item>
<item><gi>principal</gi> required, if known</item>
<item><gi>resp</gi> required, if known</item>
<item><gi>role</gi> and <gi>name</gi> required, if known, when the
            responsibility is not an author, sponsor, funding body, or
            principal researcher.  Details may be found in
            section <ptr target="hd21">.</item>
</list></item>
<item><gi>editionStmt</gi> recommended
<list>
<item><gi>edition</gi> recommended</item>
<item><gi>resp</gi> recommended</item>
<item><gi>role</gi> and <gi>name</gi> recommended primarily to
            distinguish editions.</item>
</list></item>
<item><gi>extent</gi> optional</item>
<item><gi>publicationStmt</gi> required
<list>
<item><gi>date</gi> recommended</item>
<item><gi>publisher</gi>, <gi>distributor</gi>,
          or <gi>authority</gi> required</item>
<item><gi>pubPlace</gi> recommended</item>
<item><gi>address</gi> recommended; prose is sufficient</item>
<item><gi>idno</gi> recommended</item>
<item><gi>availability</gi> recommended</item>
</list></item>
<item><gi>seriesStmt</gi> optional
<list>
<item><gi>title</gi> required</item>
<item><gi>idno</gi> recommended</item>
<item><gi>resp</gi> and <gi>name</gi> optional</item>
</list></item>
<item><gi>notesStmt</gi> recommended</item>
</list></item>
<item><gi>sourceDesc</gi> required.  As much information as possible
should be provided to identify the source.  The following tags are
either required or recommended, but other tags not listed here should be
used wherever applicable in order to provide an accurate identification
of the source.  In some instances, the <gi>biblFull</gi> tag is
preferable to the <gi>biblStruct</gi> tag.
<list>
<item><gi>biblStruct</gi> recommended.  For a full discussion
        of <gi>biblStruct</gi>, see section <ptr target="CObi">.</item>
<item><gi>analytic</gi> required when the citation describes an item
          within a larger collection, such as an essay within a
          collection or an article in a journal, and is not an
          independent publication.  If used, it should contain the
          following elements in this order:
<list>
<item><gi>author</gi> required, if known</item>
<item><gi>title</gi> required</item>
<item><gi>editor</gi> recommended</item>
</list></item>
<item><gi>monogr</gi> mandatory when applicable; this element should
        contain the following elements in this order:
<list>
<item><gi>author</gi> required, if known.</item>
<item><gi>title</gi> required.  The <att>level</att> attribute must
              be used to indicate whether this is the title of a book,
              journal, or series.  It is highly
              recommended that the <att>type</att> attribute be used
              to distinguish the main title from subordinate, parallel,
              or other titles.  All elements that indicate intellectual
              responsibility for a work, such as <gi>editor</gi>, are
              required, if known.</item>
<item><gi>imprint</gi> required.</item>
<item><gi>pubPlace</gi> required, if known.</item>
<item><gi>org</gi> recommended.</item>
<item><gi>date</gi> required.
             If the date is unknown, <code>n.d.</code> may be used.</item>
<item><gi>idno</gi> recommended.</item>
<item><gi>series</gi> required, if the item is part of a series.</item>
<item><gi>title</gi> required, but <att>type</att> attribute
          is optional.</item>
</list></item>
<item><gi>scriptStmt</gi> required for transcribed speech.
        See section <ptr target="HD32">.</item>
<item><gi>recordingStmt</gi> mandatory when applicable:
<list>
<item><gi>resp</gi> and <gi>name</gi> recommended</item>
<item><gi>recording</gi> recommended</item>
<item><gi>equipment</gi> recommended</item>
<item><gi>broadcast</gi> recommended</item>
<item><gi>comment</gi> optional</item>
</list></item>
</list></item>
<item><gi>encodingDesc</gi> very highly recommended, especially
      for projects, collections, or corpora.
      If the <gi>encodingDesc</gi> element is used, it is recommended
      that it contain one or more of the following elements, rather
      than a prose description.  See section <ptr target="HD5">.
<list>
<item><gi>projectDesc</gi> optional</item>
<item><gi>samplingDecl</gi> optional</item>
<item><gi>editorialDecl</gi> recommended; it is also recommended
          that the editorial declaration make use of the specialized
          elements defined in section <ptr target="HD53">, rather than
          only consisting of prose paragraphs.
          Prose may of course be used in addition to these
          elements for material otherwise not handled.</item>
<item><gi>tagsDecl</gi> recommended</item>
<item><gi>refsDecl</gi> optional in general, but recommended if
        a standard referencing system is built into the encoded works.
        Section <ptr target="HD54"> describes three different methods
        for documenting the referencing system:  the prose method,
        the stepwise method, and the milestone method.  No preference
        is expressed for one type of method over another, since this
        depends on the convenience of the encoder and the likely
        efficiency of the particular software applications envisaged for
        the text.  Only one method can be used within a
        single <gi>refsDecl</gi> element.  If a text uses both
        hierarchical and milestone tagging, this can only be described
        in prose.</item>
<item><gi>classDecl</gi> required where the <att>scheme</att>
        attribute has been used to identify the
        classification scheme or taxonomy used by any of the elements
    <gi>keywords</gi>, <gi>classcode</gi>, <gi>occupation</gi> or
    <gi>socecstatus</gi>. Even where this is not done, this element
    may usefully document the
    classification employed, either explicitly as a series of
   <gi>taxonomy</gi> elements, or implicitly by means of
        bibliographic citation.</item>
</list></item>
<item><gi>profileDesc</gi> recommended
<list>
<item><gi>langUsage</gi> recommended</item>
<item><gi>language</gi> recommended</item>
</list></item>
<item><gi>textDesc</gi> optional in most instances, but recommended
      when the encoder wants to provide a full description of the
      situation within which a text was produced or experienced,
      characterize it in a relatively continuous manner (in contrast
      to discrete categories based on type or topic), and believes
      that this characterization of the text will be helpful to the
      understanding, analysis, or retrieval of this text by remote
      users.  If a collection or corpus uses a pre-existing descriptive
      typology as its organizing principle, it is recommended that
      its components be re-expressed in terms of the parameters listed
      here.  If the encoder believes that pre-existing text categories
      (such as a standard classification scheme) are sufficient, then
      it is recommended that the <gi>textClass</gi> element be used
      instead. See section <ptr target="CCahtd"> for details and guidance.
<list>
<item><gi>channel</gi> required</item>
<item><gi>constitution</gi> required</item>
<item><gi>derivation</gi> required</item>
<item><gi>domain</gi> required</item>
<item><gi>factuality</gi> required</item>
<item><gi>interaction</gi> required</item>
<item><gi>preparedness</gi> required</item>
<item><gi>purposes</gi> required</item>
<item><gi>purpose</gi> required</item>
</list></item>
<item><gi>textClass</gi> optional in most instances; this element may
  may be used as an alternative or in addition to the <gi>textDesc</gi>
  element.  <gi>textClass</gi> is recommended in the following
  situations:
<list>
<item>a standard text category, such as the Library of Congress
        List of Subject Headings or a Dewey Decimal Classification
        category, clearly describes the text</item>
<item>situational parameters (or the demographic elements of
        the <gi>particDesc</gi> element) are used and a text category
        can be constructed by the encoder based on a recurring set of
        values for those parameters.</item>
</list>
  See section <ptr target="HD43"> for details and guidance. One
  or more of the following sub-elements can be used.
<list type="bullets">
<item><gi>keywords</gi> recommended only if using a standard
        thesaurus such as the Library of Congress List of Subject
        Headings, a discipline-specific thesaurus, or a thesaurus
        defined explicitly in the header. In each case, the source
        should be indicated by the <att>scheme</att> attribute and
        defined in the <gi>classDecl</gi> element.</item>
<item><gi>classCode</gi> recommended only if the text is
        categorized by an internationally accepted classification
        scheme, such as the Dewey Decimal or Universal Decimal
        classification schemes.  The scheme
        should be indicated by the <att>scheme</att> attribute and
        defined in the <gi>classDecl</gi> element.</item>
<item><gi>catRef</gi> optional in most instances, but recommended
        when a user-defined classification is in use. The scheme
        should be indicated by the <att>scheme</att> attribute and
        defined in the <gi>classDecl</gi> element.
<!-- many taxonomies defining classification schemes are      -->
<!-- used (especially with respect to collections or          -->
<!-- corpora), and the encoder finds that it is easier to     -->
<!-- group these in the <gi>encodingDesc</gi> and make        -->
<!-- reference to them using the <gi>catRef</gi> tag,         -->
<!-- rather than repeating them throughout the header.        -->
<!-- This element is also recommended when the encoder is     -->
<!-- using a specific edition of a classification scheme or   -->
<!-- taxonomy, and it is known, or assumed, that this         -->
<!-- scheme will change in the future or has changed from     -->
<!-- the past.  Bio-medical and scientific taxonomies are     -->
<!-- examples of changing classification schemes.             -->

<!-- deleted above because it doesnt seem to provide any      -->
<!-- reason for using or not using catref (lb)                --></item>

</list></item>
<item><gi>particDesc</gi> optional, but recommended for spoken
      text when the encoder judges that such information is useful
      to remote users in the analysis of that text, and for both
      written and spoken text if such information is useful in the
      analysis of language usage.  For details and guidance,
      see section <ptr target="CCahpa">.</item>
<item><gi>participant</gi> or <gi>particGroup</gi> recommended.
      Though the substructure of both the <gi>participant</gi>
      and <gi>particGroup</gi> elements can be prose, in independent headers
      one or more of the following sub-elements providing more specific
      details should be used in preference to prose.  Users of these
      Guidelines are free to extend the set of headings listed below.
<list>
<item><gi>name</gi> recommended when the information is available</item>
<item><gi>birthDate</gi> recommended when the information is available</item>
<item><gi>birthPlace</gi> recommended when the information is available</item>
<item><gi>firstLang</gi> recommended when the information is available</item>
<item><gi>langKnown</gi> recommended when the information is available</item>
<item><gi>residence</gi> recommended when the information is available</item>
<item><gi>education</gi> recommended when the information is available</item>
<item><gi>affiliation</gi> recommended when the information is available</item>
<item><gi>occupation</gi> it is recommended that, where possible,
        the classification of the trade, occupation, or profession
        be derived from a standard classification or taxonomy, and that
        the source taxonomy be identified in the <att>scheme</att>
        attribute.</item>
<item><gi>socecstatus</gi> it is recommended that, where
        possible, the encoding of social and economic status be
        derived from a standard classification or taxonomy, and that
        the source taxonomy be identified in the <att>scheme</att>
        attribute.</item>
</list></item>
<item><gi>particRelations</gi> optional, but recommended where it
is judged by the encoder that such information is important to the
analysis of the text. If the <gi>particRelations</gi> tag is used, it
is recommended that the special purpose <gi>relation</gi> element
be used.  See section <ptr target="CCahpa">.</item>
<item><gi>settingDesc</gi> optional, but recommended when the
encoder judges that this information is useful in the analysis of the
text, particular in the analysis of language usage.</item>
<item><gi>revisionDesc</gi> required in the independent header when
available.  It is recommended that the <gi>revisionDesc</gi> be encoded
with a series of special purpose <gi>change</gi> elements with grouped
<gi>name</gi>, <gi>what</gi> and <gi>date</gi> tags.</item>
</list></p></div2>

<div2 id="SHmarc"><head>Header Elements and their Relationship to the MARC Record</head>

<p>This section offers some guidance to both cataloguers and
bibliographic analysts who want to load TEI independent headers into a
MARC-based retrieval system.  Because there are variations in
cataloguing practice across local sites, among bibliographic utilities
(such as OCLC and RLIN), and differences in MARC usage in different
countries, only tentative advice is possible.  Note that the following
examples are based on USMARC, <emph>not</emph> UNIMARC.
<note>For more information on UNIMARC, see <bibl>Brian P. Holt,
<title>UNIMARC Manual</title> (London, U.K.: IFLA Universal
Bibliographic Control and International MARC Programme, British Library,
1987)</bibl>.  For USMARC, see <bibl> Walt Crawford, <title>MARC
for library use:  understanding USMARC</title> (Boston: G.K. Hall,
1989)</bibl>, <bibl><title>USMARC format for bibliographic data,
including content designation</title> (Washington, D.C.: Library of
Congress, 1987)</bibl>, and <bibl>Deborah J. Byrne, <title>MARC
manual : understanding and using MARC records</title> (Englewood, Colo.:
Libraries Unlimited, Inc., 1991)</bibl>.
</note>
UNIMARC offers cataloguers in different countries the opportunity to
combine different national practices in a single MARC format, and is the
preferred variety of MARC records for distribution
across national boundaries.  The implementation of UNIMARC, however,
will be affected by local practice and by guidelines offered by the
bibliographic utilities. Though UNIMARC is a stable format, the
guidelines for its implementation are not sufficiently known or
stabilized to be included in this chapter.</p>

<p>There are some major differences between the MARC record and the TEI
header that will cause problems for librarians trying to map from the
TEI independent header to the MARC record.  The most important
difference between the MARC record and the TEI header is the function of
each.  Despite the efforts and claims of some members of the library
community, the MARC record remains fundamentally an electronic version
of the catalogue card, with the limitations of its model.
<note place="foot">The primary function of the MARC record when it was
first designed in the mid-1960s was to allow for the electronic
distribution of cataloguing records in support of card production.  See
<bibl>Henriette Avram, <title> The MARC Pilot Project</title>
(Washington D.C.:  Library of Congress, 1968), p.  3.</bibl> For
discussion of the relationship between the MARC record and the catalogue
card, see <bibl>Michael Gorman, "After AACR2R: The Future of the
Anglo-American Cataloging Rules," in Richard Smiraglia, ed.,
<title>Origins, Content and Future of AACR2 Revised</title> (Chicago:
American Library Association, 1992)</bibl>.
</note>
The catalogue card is a unitary record for a physical object containing
complex <emph>bibliographic data</emph> of varying sorts.  The catalogue
card points to the physical object.  The TEI header provides full
bibliographic information (as would a card), as well as documentary
non-bibliographic information that supports the analysis, either by
humans or machines, of the electronic text documented by header.  Most
of this analytical information, which is found in profile description,
encoding description, and revision history, has little direct provision
for it in the MARC record,
<!-- except that they can be stuffed into various notes (5XX) fields. -->
and if retained must be recorded as unstructured notes (55XX) fields.
Notes fields usually do not have the structure to support machine
retrieval and analysis, while properly formatted profile, encoding, and
revision descriptions lend themselves to retrieval, can support machine
processing (including analysis), and point directly to the electronic
text attached to the header.  Moreover, the electronic text points back
to the relevant elements in the header.</p>

<p>Though this chapter offers some advice on where the profile,
encoding, and revision descriptions might go in a MARC record, for
practical reasons a repository might want create a codebook from these
divisions of the header, and create a MARC record from the file
description only.  The MARC record should contain a reference to the
codebook.</p>

<p>Subfields (or delimiters) are conventionally indicated by the
dollar sign.</p></div2>

<div2 id="SHfd"><head>MARC Fields for the File Description</head>

<p>Note that there is no provision for the <socalled>Main
Entry</socalled> (or USMARC <code>1XX</code> fields) in the TEI
header.  The main entry should be constructed, using appropriate name
authority control, by the cataloguer from information derived from the
header that indicates who is primarily responsible for the
intellectual content of the work.  There is an <gi>author</gi> tag,
but the form of the name will have to be checked by a cataloguer
before the main entry is constructed.

<list>
<item><gi>titleStmt</gi> corresponds to title and statement of
responsibility fields in MARC, typically <code>240</code> (for uniform
title) and <code>245</code> (for title proper).</item>
<item><gi>title</gi> <code>240 $a</code> (for uniform titles) or
<code>245 $a</code> fields.  Put any subtitles in <code>24X $b</code>.
Insert the constant, <q>[computer file]</q> in the <code>24X $h gmd</code>
subfield.</item>
</list></p>

<p>The following elements belong in the <code>245 $c</code> subfield:
statement of responsibility.

<list>
<item><gi>sponsor</gi></item>
<item><gi>funder</gi></item>
<item><gi>principal</gi></item>
</list>

Example:
<eg>
<![ CDATA [
<titleStmt>
  <title>Two stories by Edgar Allen Poe: electronic
         version</title>
  <author>Poe, Edgar Allen (1809-1849)</author>
  <respStmt><resp>compiled by</resp>
  <name>James D. Benson</name></respStmt>
]]>
</eg>

This might be tagged in MARC as:

<eg>
245 Two stories by Edgar Allen Poe :$belectronic version ;
    compiled by $cJames D. Benson.
</eg>

<list>
<item><gi>edition</gi> <code>250 $a</code></item>
<item><gi>name</gi> <code>250 $b</code></item>
</list>

Example:

<eg>
<![ CDATA [
<editionStmt><edition>
    Student's edition,
    <date>June 1987</date>
</edition><respStmt>
    <resp>New annotation by</resp>
    <name>George Brown</name>
</respStmt></editionStmt>
]]>
</eg>
<!-- N.B. the awkward tagging here is required by the fact    -->
<!-- that editionStmt *can* contain phrase data.  It ought    -->
<!-- to be just p instead. (msm)                              -->

This might be tagged in MARC as:

<eg>
250  $aStudent's edition, June, 1987, new annotation by
     $bGeorge Brown.
</eg>

<list>
<item><gi>extent</gi>.  The extent is analogous to the
<socalled>Physical Description</socalled> MARC field.  Fields
<code>256</code> or <code>3XX</code>, depending on local practice are appropriate.</item>
<item><gi>date</gi> <code>260 $c</code>, and appropriate fixed fields.</item>
<item><gi>publisher</gi>, <gi>distributor</gi>, or <gi>authority</gi>
       <code>260 $b</code></item>
<item><gi>pubPlace</gi> <code>260 $a</code></item>
</list>

Example:
<eg>
<![ CDATA [
<publicationStmt>
  <publisher>Columbia University Press</publisher>
  <pubPlace>New York</pubPlace>
  <date>1993</date>
</publicationStmt>
]]>
</eg>
This may be tagged in MARC as:
<eg>
260 $aNew York :$bColumbia University Press, $c1993.
</eg></p>

<p>Local practice will determine appropriate MARC fields for
<gi>address</gi>, <gi>idno</gi>, and <gi>availability</gi>.
Restrictions on access should normally be placed in the
<code>506</code> field, while the place where an item may be ordered
will be located in a local notes (<code>590</code>) field.  If local
practice warrants it, the address of the publisher should be indicated
in the <code>260</code> field.</p>

<p>The series <gi>title</gi> and the <gi>idno</gi> should be placed in
the appropriate <code>490</code> fields (series untraced), if series
authority checking needs to be done.  Further, because the TEI tags do
not differentiate between name, conference, or title series, there is
no simple mechanical method for determining which MARC tag (<code>410,
411,</code> etc.)  should be used.  Safe practice would be to load any
series statements into <code>490</code> fields, and then to conduct
authority work on those fields.

<list>
<item><gi>notesStmt</gi> These are usually reserved for general notes
(<code>500</code>) fields.</item>  </list></p>

<p>The <gi>sourceDesc</gi> can be mapped to be a <socalled>source of
data</socalled> note (<code>537</code> in RLIN MDF format) with the
print constant <q>Transcribed from:</q> at the beginning of the note.
The <gi>biblStruct</gi> itself can be mapped onto a <code>581</code>
field (note on primary publication) using the ISBD format to separate
each data element.</p>

<p>The <gi>scriptStmt</gi>, <gi>recordingStmt</gi>,
<gi>recording</gi>, <gi>equipment</gi>, and <gi>broadcast</gi>
elements do not easily map to existing MARC fields, and should be
put into a local notes field (<code>590</code>) treating the TEI tag
introducing each component as a print constant at the head of the
field in order to facilitate future local processing and retrieval.

Example:
<eg>
<![ CDATA [
<scriptStmt id=CNN12>
  <bibl><author>CNN Network News</author>
    <title>News Headlines</title>
    <date>12 Jun 1991</date>
  </bibl>
</scriptStmt>
]]>
</eg>

This may be tagged in MARC thus:

<eg>
<![ CDATA [
590  <scriptStmt id=CNN12>
     <bibl><author>CNN Network News</author>
     <title>News Headlines</title>
     <date> 12 Jun 1991></date></bibl>
     </scriptStmt>
]]>
</eg>

Example:

<eg>
<![ CDATA [
<recordingStmt>
   <recording type=video dur="10 mins">
   <equipment><p>Recorded from FM radio to chrome
       tape</p></equipment>
   <broadcast>
      <bibl>
         <title>Britain's pleasure parade</title>
         <author>BBC Radio 4 FM</author>
         <editor role=interviewer>Robin Day</editor>
         <editor role=interviewee>Margaret Thatcher</editor>
         <series><title>The World Tonight</></series>
         <date>27 Nov 89</date>
       </bibl>
    </broadcast>
    </recording>
</recordingStmt>
]]>
</eg>

This can be tagged in MARC as:
<eg>
<![ CDATA [
590 <recordingStmt>
    <recording type=video dur="10 mins">
    <equipment><p>Recorded from FM radio to chrome
         tape</p></equipment><broadcast>
    <bibl><title>Britain's pleasure parade</title>
    <author>BBC Radio 4 FM</author>
    <editor role=interviewer>Robin Day</editor>
    <editor role=interviewee>Margaret Thatcher</editor>
    <series><title>The World Tonight</></series>
    <date>27 Nov 89</date>
    </bibl>
    </broadcast>
    </recording>
    </recordingStmt>
]]>
</eg></p></div2>

<div2 id="SHed"><head>MARC Fields for the Encoding Description</head>

<p>The <gi>encodingDesc</gi> element provides useful information
documenting the relationship between an electronic text and the source
or sources from which it was derived.  The <gi>projectDesc</gi>,
<gi>samplingDecl</gi>, <gi>editorialDecl</gi>, and <gi>refsDecl</gi>
elements provide details of decisions and rationales used about the
process and purposes of the project, how text was sampled, principles
of editorial practice, and how canonical references are constructed.
The <code>567</code> field (notes on methodology) appears to be the
most appropriate for this sort of information, though this field is
normally intended for methodologies characterizing the social
sciences.  Practically, it would be wise to transcribe the
<gi>projectDesc</gi>, <gi>editorialDecl</gi>, <gi>refsDecl</gi>, and
<gi>classDecl</gi> elements directly as one or more 567 fields without
intervention, with the element name at the beginning of each field,
and any TEI tags left intact. This may facilitate any
locally-developed retrieval software.</p>

<p>Example:

<eg>
<![ CDATA [
<encodingDesc>
  <projectDesc><p>Texts were collected to illustrate the
    full range of twentieth-century spoken and written Swedish,
    written by native Swedish authors.</projectDesc>
  <samplingDecl><p>Sample of 2000 words taken from the
    beginning of the text.</p></samplingDecl>
  <editorialDecl>
       <interpretation><p>Errors in transcription controlled
         by using the SUC spell checker, v.2.4</p></interpretation>
  </editorialDecl>
</encodingDesc>
]]>
</eg>

This may be tagged in MARC as:

<eg>
<![ CDATA [
567  <projectDesc><p>Texts were collected to illustrate the
      full range of twentieth-century spoken and written
      Swedish, written by native Swedish authors.</p>
567  <samplingDecl><p>Sample of 2000 words taken from the
     beginning of the text.</p>
567  <editorialDecl>
     <interpretation><p>Errors in transcription controlled
      by using the SUC spell checker, v. 2.4</p>
     </interpretation>
     </editorialDecl>
]]>
</eg></p></div2>

<div2 id="SHpd"><head>MARC Fields for the Profile Description</head>

<p>The profile description is the most problematic element in the TEI
header for librarian cataloguers, because it provides a detailed
description of the <emph>non-bibliographic</emph> aspects of the text,
specifically the languages and sublanguages used, the situation in which
it was produced, and the participants and their setting.  This
information can be used for retrieval purposes or in
machine-supported analysis of the text.  The information can be loaded
into a separate <socalled>codebook</socalled> and referenced by the MARC
record.  Little guidance can be offered on the appropriate MARC
location for the elements that make up the profile description, except
to suggest that if a site wants to load the profile description into a
MARC record for archival and possibly retrieval purposes, then the
contents of the profile description may be mapped into a locally-defined
notes field (<code>59X</code>) with its TEI tags intact, as in the examples
above.</p></div2>

<div2 id="SHrd"><head>MARC fields for the Revision Description</head>

<p>The revision history (<gi>revisionDesc</gi>) logs all changes to a
machine readable file whether or not these constitute a new edition of
the file.  Aside from the edition area of the MARC record, there are
no MARC fields that deal specifically with changes of this sort.  This
information might be best included in a <socalled>codebook</socalled>,
rather than a MARC record. As before, the simplest way of approaching
this problem is to include the material with its TEI tags intact as a
locally-defined note (<code>59X</code>) in order to support future
local processing.</p></div2>

<div2 id="SHstr"><head>Structure of the DTD for Independent Headers</head>

<p>The following document type definition is provided in file
<ident type="file">teishd2.dtd</ident> and constitutes the auxiliary DTD for
independent headers as described in this chapter.

<eg id=dih>
<![ CDATA [
<!-- 24.8: File teishd2.dtd: Auxiliary DTD for Independent    -->
<!-- Header                                                   -->
<!-- Text Encoding Initiative: Guidelines for Electronic      -->
<!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

<!-- Copyright (c) 1994 ACH, ACL, ALLC. Permission to copy    -->
<!-- in any form is granted, provided this notice is          -->
<!-- included in all copies.                                  -->

<!-- These materials may not be altered; modifications to     -->
<!-- these DTDs should be performed as specified in the       -->
<!-- Guidelines in chapter "Modifying the TEI DTD."           -->

<!-- These materials subject to revision. Current versions    -->
<!-- are available from the Text Encoding Initiative.         -->

<!-- Embed entities for TEI generic identifiers.              -->

<!ENTITY % TEI.elementNames system 'teigis2.ent'                >
%TEI.elementNames;

<!-- Embed entities for TEI keywords.                         -->

<!ENTITY % TEI.keywords.ent system 'teikey2.ent'                >
%TEI.keywords.ent;

<!-- Define element classes for content models, shared        -->
<!-- attributes for element classes, and global attributes.   -->
<!-- (This all happens within the file teiclas2.ent.)         -->

<!ENTITY % TEI.elementClasses system 'teiclas2.ent'             >
%TEI.elementClasses;

<!-- Now declare the IHS element.                             -->

<!ELEMENT ihs           - O  (teiHeader+)                       >
<!ATTLIST ihs                %a.global;                         >

<!-- Finally, embed the TEI header and core tag sets.         -->

<!ENTITY % TEI.header.dtd system 'teihdr2.dtd'                  >
%TEI.header.dtd;
<!ENTITY % TEI.core.dtd system 'teicore2.dtd'                   >
%TEI.core.dtd;
]]>
</eg>
</p>

<p>The overall structure of a set of independent headers, encoded for
interchange as a group, is thus:

<eg>
<![ CDATA [
<!DOCTYPE ihs PUBLIC "-//TEI P3//DTD Auxiliary Document Type:
        Independent TEI Header//EN"
       "teishd2.dtd">
<ihs>
<teiHeader>
  <fileDesc> ...     </fileDesc>
  <encodingDesc> ... </encodingDesc>
  <profileDesc> ...  </profileDesc>
  <revisionDesc> ... </revisionDesc>
</teiHeader>
<teiHeader>
  <fileDesc> ...     </fileDesc>
  <encodingDesc> ... </encodingDesc>
  <profileDesc> ...  </profileDesc>
  <revisionDesc> ... </revisionDesc>
</teiHeader>
<teiHeader> ... </teiHeader>
<!-- ... etc. -->
</ihs>
]]>
</eg></p>

<p>In practice, headers might be stored in separate operating system
files, to reduce redundant storage requirements; in this case, the
top-level file for a typical document might have the following
structure:
<eg>
<![ CDATA [
<!DOCTYPE tei PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                     "tei2.dtd" [
  <!ENTITY txt01 system 'text01.tei' >
  <!ENTITY hdr01 system 'text01.hdr' >
]>
<tei.2>
&hdr01;
&txt01;
</tei.2>
]]>
</eg>

while that for a set of independent headers might have this structure:

<eg>
<![ CDATA [
<!DOCTYPE ihs PUBLIC "-//TEI P3//DTD Auxiliary Document Type:
        Independent TEI Header//EN"
       "teishd2.dtd" [
  <!ENTITY hdr01 system 'text01.hdr' >
  <!ENTITY hdr02 system 'text02.hdr' >
  <!ENTITY hdr03 system 'text03.hdr' >
  <!-- ... etc. -->
]>
<ihs>
&hdr01;
&hdr02;
&hdr03;
<!-- etc. -->
</ihs>
]]>
</eg>
</p>
</div2>
</div1>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:("/home/tei/P3/Master/Odds/p2.odd" "TEI.1" "TEXT" "BODY" "DIV1")
sgml-omittag:t
sgml-shorttag:t
End:
-->
             <!-- 24 Structured Header -->
