Dear Mike

Many thanks for your careful reading and useful comments. Brief
reactions noted below. 

Lou


>TEI 24: The Independent Header
>
>Disclaimer & Proposal: I was allocated this chapter for review because I
>expressed an interest in being able to map TEI headers to emerging
>resource discovery protocols such as the Z39.50 Bath Profile and the Open
>Archive Initiative metadata protocol. Both make use of the Dublin Core
>Metadata Element Scheme as the default means of attaining
>interoperability. Thus it seems sensible to document a possible mapping
>between TEI Header elements and Dublin Core elements so that electronic
>text providers might take advantage of OAI and Bath Profile developments,
>for example, in a consistent manner. It is beyond the scope of a simple
>review of Chapter 24 to make any detauled suggestions of how this may be
>accomplished except to recommend that the Chapter commences with a short
>paragraph explaining that the TEI intends to explore the (re)creation of
>an TEI interoperability working group and that it acknowledges that there
>are more protocols and schemes available now than when the chapter was
>first written when MARC appears to have been the only serious scheme to
>which one would have wanted to convert ones headers. 

Good idea: suitable wording? &winita;

>The working group (or
>whatever appropriate mechinism is developed) might also include within its
>remit the creation of a TEI XML namespace (and XML schema) for the TEI
>Header at least. This would, in theory, permit the expression of a TEI
>Header (or its parts) within RDF(-like) statements 

We are working on definition of an XML schema for the whole of the TEI
scheme, including the header, as a high priority. I'm not sure what
you mean by "creation of a TEI XML namespace", but presumably that
would come as part of the same exercise.

>or possibly avoid the
>need for rather awkward solutions such as the recommendation that certain
>TEI Header constructs be reproduced 'as is' (i.e. with tags intact) within
>locally defined MARC fields.

Definitely a bad idea imho, but I don't see what we can do about it.

> I have no knowledge of MARC and therefore
>have no suggestions to make concerning the MARC material within this
>chapter save that other mappings should also be planned for inclusion.
>
>Suggested amendments
>
>Replace 'machine-readable' throughout with 'electronic' or 'digital'

Will look into that. We use the term consistently throughout the
header chapter. Are you suggesting that should also change? Any
particular reason?

>Definition or alternative term for 'codebook'? Perhaps 'metadata record'
>or similar?

A "codebook" explains what the codes used in (typically) social
science dataset stands for. Although that is a kind of metadata, I
don't think it's quite synonymous.


>24.0 Para 2. Include sentence to the effect that the distribution and
>retrieval of independent headers facilitate resource discovery. MARC is
>one example of the reuse of information embedded in TEI Headers; recent
>developments such as the Open Archives Initiative protocol and the Z39.50
>Bath Profile (Interoperability) are examples of protocols for data
>exchange which assume a minimum support of simple Dublin Core expressed in
>XML.

Have added the following para after para 2 (before "<p>The structure
of an independent header is exactly the same as that of a
<gi>teiHeader</gi>..."):

<p>The distribution and retrieval of independent headers also
facilitates resource discovery by other means. The mappings to MARC
discussed in the remainder of this section form one example of how the
information embedded in TEI Headers may be re-used; with more recent
developments such as the Open Archives Initiative protocol and the
Z39.50 Bath Profile (Interoperability) it becomes possible to define
other protocols for data exchange. A key element here will be the
establishment of mappings between the components of the TEI header and
those of the Dublin Core expressed in XML. It is hoped to document
such mappings in future editions of these Guidelines. </p>

Can you provide references for OAI, Bath Profile and DC?


>24.2.
>
>publicationStmt. Chapter 5 implies that the order of elements within
>publicationStmt is significant. In which case, 'date' should follow
>availability. [actually, the examples in chap 5 are at variance with the
>order of elements given?]
>

The order cannot be constrained by the XML dtd, but there is
a prescribed order which a TEI processor should enforce. I've added a
note to the tagdoc to point this out, fixed one  example, and
moved date to its rightful place in the list

>sourceDesc. The chapter implies sourceDesc is a component at the same
>level as fileDesc whereas it is actually the final component within
>fileDesc.

Tsk tsk. Fixed.

>
>I would like the reader to be reminded that, although mandatory, the
>Guidelines do acknowledge that many electronic texts have no 'source' and
>in which case something like the following is recommended:
>
><sourceDesc>
>   <p>No source: born digital.</p>
></sourceDesc>
>

OK. Have revised as follows:

<item><gi>sourceDesc</gi> required.  As much information as possible
should be provided to identify the source, where one exists.  In the
case of items <soCalled>born digital</soCalled>, the source
description is still mandatory, and should contain a note like the
following:<eg><![CDATA[
<sourceDesc>
   <p>No source: this document was created in digital form.</p>
</sourceDesc>
]]></eg>. Where the source document is itself a TEI document, the
<gi>biblFull</gi> element should be used, as discussed in section <ptr target="HD31"/>.
In other cases, the following elements are...


>profileDesc. This component contains textDesc, textClass, particDesc,
>settingDesc - all of which should be second-level list items in this
>chapter.

Tsk tsk. Fixed.

>
>participant, particRelations are sub-components of particDesc (I think)
>and therefore should be relegated to third-level items.

Tsk tsk. Fixed.

>
>[There is possibly an over-emphasis on elements drawn from language
>corpora in this section - I think the formatting can be simplified to
>remind the reader of the basic TEI Header with only mandatory or highly
>recommended elements repeated, except where the recommendation differs
>from that in chap 5 - not that there should be any difference, every
>creator of TEI Headers should create Headers fit for reuse!]

How? I have removed the list of components for <textDesc> which seem a
bit unnecessary.

>
>revisonDesc. What's a 'what' tag?  Perhaps rephrase to read: "It is
>recommended that the revisionDesc be encoded with a series of special
>purpose change elements with grouped  date, respStmt and item elements in
>reverse chronological order."

The <what> tag was in P1. Amazing how these things lurk... We
changed the content model of <change> since this chapter was last
looked at and forgot to change it here. Ah well. Now fixed.

>
>A cross-reference to '5.6 Minimal and Recommended Headers' might
>fruitfully be included at the end of 24.2.

OK


>24.3+ No major comments. Don't know MARC.

OK

>24.4
>The scriptStmt...
>Example tagged in Marc has spurious &gt; ("<date> 12 Jun 1991&gt;</date>")
>

Whoops. Fixed.
