SourceForge has been redesigned. Learn more.
Close

#35 A place for out-of-line elements

DS
closed
6
2007-02-16
2004-09-05
Syd Bauman
No

There exist content objects that I would like to have
in my TEI file that are neither part of the original
work being encoded per se, nor are really part of the
"metadata" that is the <teiHeader>, either.

Examples include:
- the <castList> of a drama if no cast list appeared in
the source;
- the keyed list of names that occur in the document[1]
- <timeline> elements
- <linkGrp> or <joinGrp> elements
- <note> elements (other than those in the <notesStmt>)
that
one chooses not to encode in-line or in-place.[2]

These elements belong inside the main <TEI.2> element,
but do not belong inside the <teiHeader> or the
<front>, <body>, or <back> elements. It is arguable
whether they belong inside the <text> element or outside.

This suggestion is for an element (called <hyperDiv>;
the name <ldb> has also been suggsted, for "link data
block"; alternatively, it might just be an <ab>,
although that would make appropriate constraints
difficult or impossible) which would occur as an
optional single child of <text> before <front>, whose
express purpose would be to hold this sort of thing.

Notes
-----
[1] Were a project to decide to make key= of <name> an
IDREF
or XPointer, so that it could point to a database
stored
in the same instance.
[2] By "in-line" I mean the standard OHCO method of
encoding
<note>s at their anchor point in the text. By
"in-place"
I mean encoding a note where it appeared on the source
page.

Discussion

  • Lou Burnard

    Lou Burnard - 2004-09-17

    Logged In: YES
    user_id=1021146

    List of names should probably go in whatever replaces
    <particDesc> in the header. But I agree something like this
    would be handy. But why not put it in the header?

     
  • Lou Burnard

    Lou Burnard - 2004-09-22
    • labels: --> TEI: New or Changed Element
    • priority: 5 --> 6
    • assigned_to: nobody --> sbauman
     
  • Conal Tuohy

    Conal Tuohy - 2005-09-05

    Logged In: YES
    user_id=689468

    Would this be an appropriate place to encode full-page scans
    of the source document, too?

     
  • Syd Bauman

    Syd Bauman - 2007-02-02
    • milestone: --> DS
     
  • Christian Wittern

    Logged In: YES
    user_id=222320
    Originator: NO

    To me, this type of data would best be housed in the teiHeader, specifically in the profileDesc section. Now looking there, it seems to me that this is a tick specific for corpus linguistics, and should perhaps be generalized for other purposes.
    Christian

     
  • Lou Burnard

    Lou Burnard - 2007-02-16
    • assigned_to: sbauman --> louburnard
     
  • Lou Burnard

    Lou Burnard - 2007-02-16
    • status: open --> closed
     
  • Lou Burnard

    Lou Burnard - 2007-02-16

    Logged In: YES
    user_id=1021146
    Originator: NO

    The consensus appears to be in favour of putting most such data in the TEI Header rather than creating a completely new location for it. As CW says, the <profileDesc> is provided for just such a purpose.
    Taking the specific cases you mention:

    - the <castList> of a drama if no cast list appeared in the source;
    I don't think you should use <castList> unless you are encoding an actual cast list. If there is none in the source, but you want to list the roles within a dramatic text, I would suggest using <particDesc>

    - the keyed list of names that occur in the document[1]
    <particDesc> again

    - <timeline> elements
    These perhaps could go in the text somewhere for processing convenience (the only systems I know of which implement such things aside from the TEI always put them in the text certainly) In which case we might argue foradding these to model.divTop, since if you use them at all you will want them at the start of a section.

    - <linkGrp> or <joinGrp> elements
    I'm not sure about these, because I'm not sure of how you envisage their being used. What about <interp> and <interpGrp>?

    - <note> elements (other than those in the <notesStmt>)
    that one chooses not to encode in-line or in-place.[2]
    Doesn't this depend very much on your source text? If the notes are actually there in the source text then they should go into the <text>, and whether you put them at the place of attachment, the place of rendition, or in some specially labelled div in back or front really doesn't matter. If they are *not* present in the text, then they really ought to go in the header, and <notesStmt> is as good a place as any.

    I propose to close this ticket for now (i.e. I don't think we've got a clear enough mandate to get it into P5 1.0)