Yes, thanks -- that's the way I'm going to proceed.
I'm very happy to have had the discussion in this thread and the
On 23/02/15 10:56, Lou Burnard wrote:
> Thanks for the exposition. I think you should definitely adopt the
> <facsimile> approach, since that *is* sticking to the book, modulo only
> a rather rarefied and unhelpful distinction between the text and a
> representation of it. And it was invented precisely for the purposes you
> state -- to "describe a text that has been scanned into a PDF ... a
> header that will accompany a digitised version of the text that's
> currently in the PDF format.... the same header will reference both the
> PDF and the TEI-fied text "
> Of course, <facsimile> is not available in TEI Lite. But for a
> pedagogic exercise like this you should probably be defining your own
> TEI-super-lite anyway.
> On 22/02/15 23:13, Piotr Bański wrote:
>> Dear Lou,
>> I really like it when you talk history. Thanks!
>> About <ihs> as such I do not care, having the existing well-maintained
>> teiHeader and the power of ODD/RNG/XInclude to customize it any which
>> way I like. What I was concerned with, having read Fabio's reply in
>> another thread (on @mimeType), was that somehow, the TEI has rejected
>> the *concept* of an independent header, in favour of other existing
>> schemas. Peter's message suggesting that it may automatically be
>> denied a stamp of conformance has only added to my worries.
>> Update: in the list's archive and on its way to my mailbox eventually,
>> I can see a reply from Fabio in which he confirms this point of view.
>> I am very curious about the motivation for that claim and I am
>> wondering if I have been misunderstood in my aims -- so here's a short
>> statement of my intentions:
>> I do not claim that the TEI is there to eliminate all other electronic
>> formats for library records. I simply do a TEI-oriented project, part
>> of which involves a preparation of a TEI header. Currently, the header
>> can only describe a text that has been scanned into a PDF. Eventually,
>> my header will become the basis for a header that will accompany a
>> digitised version of the text that's currently in the PDF format.
>> There are several goals here, and some of them are didactic, and
>> therefore I try very hard to hold my horses and stick to the book as
>> much as I can, to make it easier for students and people who will be
>> involved later in the process of conversion to TEI XML, to follow and
>> understand, and be able to relate to other examples that they may
>> encounter. I have even decided to use TEILite! :-)
>> It would be quite an interesting finding, in the process of "going by
>> the book", to see that said book actually discourages the very thing
>> that I try to achieve at this step, namely a header that (out of
>> necessity) stands separately, -->just because it is separate<--.
>> That's why I started this thread, somewhat intrigued about the
>> potential reasons for such a point of view that might have escaped me.
>> My temporary conclusion is that there's still hope that in preparing
>> and then describing my independent header to the students, I will not,
>> for once, be a heretic. But, let's wait and see...
>>  Although in my case, there is a TEI element at the root all right
>> -- so in the shallowest sense, my independent header does conform,
>> because it consists of a <teiHeader> followed by an impoverished
>> <text>, both under <TEI>.
>>  And maybe even the same header will reference both the PDF and the
>> TEI-fied text -- an idea that I have began to fancy over the last few
>> days and that in some way goes back to my presentation from 2009 at
>> the digitisation-related TEI-MM. Hmm.
>> On 22/02/15 19:03, Lou Burnard wrote:
>>> Hi Piotr
>>> If you do a quick search through the archives, you will find that the
>>> decision to abandon the "independent header" was quite deliberate,
>>> nothing to do with conceit, and followed quite a bit of independent
>>> research. We seem to be weak on institutional memory, so here's a brief
>>> summary of some of the salient events.
>>> In P4, there was a chapter which defined an "independent header". It
>>> defined one element (<ihs>) which could be used (rather than <TEI.2>) as
>>> the root element of an SGML dtd for documents containing only
>>> <teiHeader> elements. It also contained some (lengthy) discussion of
>>> mapping between elements of the header and other library standards,
>>> notably MARC.
>>> Reviewing the components of P4, in April 2004, the Metalanguage
>>> workgroup noted that the concept of "auxiliary DTD" is no longer
>>> relevant in the P5 architecture, and that specifically "The IHS is an
>>> artefact to enable a valid document consisting only of headers, which
>>> could be accomplished in other ways."
>>> [http://www.tei-c.org/Activities/Workgroups/META/mew07.xml] The "other
>>> ways" they had in mind were presumably defining an appropriate ODD or
>>> embedding TEI Header elements inside a document in another namespace.
>>> The council meeting in July 2004
>>> (http://www.tei-c.org/Activities/Council/Meetings/tcm12.xml) notes
>>> concerns that the library-standards-mapping aspects of the old chapter
>>> should not be lost, and that its material should be reworked either as a
>>> new chapter or (as eventually happened) as a component of the existing
>>> header chapter. . No-one seems to have argued for retaining an
>>> element like the old <ihs> in P5, and no serious use case was proposed
>>> for it.
>>> Two members of the Libraries SIG, who were also members of the Council,
>>> did start work on a revision of the old chapter in a bid to bring its
>>> recommendations on best practices for interoperability up to date and a
>>> draft of this document was considered for inclusion in P5. However,
>>> at the April 2007 Council meeting
>>> (http://www.tei-c.org/Activities/Council/Meetings/tcm30.xml) where the
>>> status of all P5 drafts chapters was reviewed, Council felt the work was
>>> incomplete, probably out of scope for the Guidelines, and better
>>> handled by the Libraries community. . Again, there is no record of
>>> any proposal for a possible container element for a set of <teiHeader>
>>> In February and March 2013, there was a brief discussion of this "ghost"
>>> chapter on the Council mailing list, which reiterates (most of) the
>>> history I have summarised above, and re-affirms that the best way
>>> forward is to incorporate recommendations from the Libraries community
>>> into the Header chapter. Kevin Hawkins concluded this by observing [on
>>> 17/03/2013] "To close the loop (you all know how much I like to do
>>> that), I now think it would be better to leave this unfinished work as
>>> is and focus instead, as we've previously discussed, on incorporating
>>> relevant portions of the Best Practices for TEI in Libraries into the
>>> Since that date, there have indeed been a few proposals for change to
>>> the Header chapter addressing this need. But no-one till now has asked
>>> for anything like the old <ihs> to be reinstated. As I said before, it
>>> is hard to see what the use case for such an element would be, given the
>>> availability of other mechanisms for doing the same job.
>>>  "Noting the intention to remove the chapter on the Independent
>>> Header, P[erry] W[illett] commented that members of the Libraries SIG
>>> attached considerable importance to the material presently in that
>>> chapter about the relationship between the TEI Header and other metadata
>>> schemes, which should be maintained and updated. Council noted that
>>> there was a need for such comparative information, whether or not the
>>> independent header module was retained as a distinct schema. It was
>>> agreed that the editors should try to draft a discussion of related
>>> issues which might become part of the header chapter or a free standing
>>> Action [by 1 sep 2004] editors: draft document discussing
>>> relationship of TEI Header to other meta standards on the basis of
>>> material already available, to be handed to the TEI Libraries SIG for
>>> improvement and updating."
>>>  The draft lingers on in the TEI source tree at
>>>  " M[atthew] D[riscoll] recommends chapter be dropped. J[ohn] W[alsh]
>>> (co-author of the re-write) concurs. JW was assigned to draft a few
>>> paragraphs discussing the relationship between the TEI Header and other
>>> standards (including MARC and Dublin Core) in general terms, without
>>> detailed mappings.
>>> Action 52: JW TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/336 .
>>> Draft paras on metadata standards 2007-05-05
>>> Action 53: SB put JW paras in appropriate place at end of HD
>>> 2007-05-12 "
>>> On 21/02/15 20:32, Piotr Bański wrote:
>>>> Hi Peter,
>>>> Thank you for the response! Well, the header I've just prepared has a
>>>> <p> under <text> and <body>, which contains a single sentence with a
>>>> single <ref> in it. Of course, this can be called, hmm, abuse of the
>>>> But it's the intentions that I'm interested in. Independent headers
>>>> used to be printed on many of the flags that the TEI once waved. Have
>>>> we got so conceited as to burn them all? A lot of selling points gone
>>>> in that smoke, it seems.
>>>> Best regards,
>>>> Piotr (rubbing his hands in anticipation...)
>>>> On 21/02/15 21:05, Peter Stadler wrote:
>>>>> Others will probably be able to tell you more on the historic shift
>>>>> from P4 to P5 but to my knowledge a TEI P5 conformant document *must*
>>>>> contain "a single teiHeader element followed by a single text
>>>>> element, in that order“ [1,2] (I’m skipping the teiCorpus stuff and
>>>>> note that we introduced model.resourceLike which can replace <text>,
>>>>> but still, there has to come something after <teiHeader>)
>>>>> So, officially there are no independent headers any more, I’d say!?
>>>>> Hope that helps
>>>>>  http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-TEI.html
>>>>>> Am 20.02.2015 um 12:02 schrieb Piotr Bański <[log in to unmask]>:
>>>>>> Hi all,
>>>>>> Are independent/free-standing TEI headers gone with P4?
>>>>>> I can't find any mention on them, either in the P5 guidelines or in
>>>>>> the wiki.
>>>>>> I can find this, though:
>>>>>> And a poster from TEI@20, by Michelle Dalmau and Melanie Schlosser,
>>>>>> addressing among others "alternatives to the [independent header
>>>>>> schema] in light of P5" (which might just indicate a change of the
>>>>>> technology for maintaining said schema).
>>>>>> I'll be grateful for any pointers and information.
>>>>>> Best regards,