#94 footnote references: ptr or ref?


In P5, 16.1.2 gives nice examples of how to encode complicated footnotes assuming there is no footnote reference in the text (like a superscript number). You can either use "implicit pointing", putting the note element at the point of reference, or use "explicit" pointing, with a ptr element at the point of reference.

But what if there is a superscript number? Should you use ptr or ref? My inclination is to use ref, similar to the second TOC example in 4.5 (which has page number references, unlike the first TOC example). It seems to me that footnote references are such a common encoding need that P5 should be explicit about how to do this (with an example).


  • Lou Burnard

    Lou Burnard - 2009-10-01

    The superscript number is something about which opinions vary: it's rather like the numbering or bullets of a list, or the quote marks of a quotation. I am not sure that everyone would agree that encoding them explicitly (with ref) rather than implying them (with ptr) was a common encoding need but it's certainly an option that should be suggested in the text, if it isn't already.

  • Lou Burnard

    Lou Burnard - 2009-10-01
    • milestone: --> GREEN
  • Syd Bauman

    Syd Bauman - 2009-10-04

    I think Kevin is right. The Guidelines should have an example of a non-inline encoding of a note where there is a footnote reference in the text (and perhaps also in the note itself). Something like
    <ref xml:id="a51" type="noteAnchor">&#x2075;&#x00B9;</ref>
    <!-- ... -->
    <note target="#a51" type="footnote"><label>&#x2075;&#x00B9;.</label> See also … </note>
    That said, I think it is also important that the Guidelines make clear that this is not the only way of handling this situation, that it is perfectly reasonable (and conformant TEI) to leave the little superscript digits (or other marker) out and use <anchor> (or whatever) and <note> without the actual marker being explicitly represented as content. This is a particularly useful approach if either
    a) generated output does not need to be particularly faithful to the exact characters used as a marker, or
    b) the processes to which the text will be put do not involve the footnote markers at all (e.g., calculating the average number of syllables per sentence in main text vs annotation)

  • Lou Burnard

    Lou Burnard - 2009-11-06

    At rev #6937 I've revised the text a bit to licence the explicit encoding of the point of attachment siglum, and added a simple example. Syd's example points from the note to the footnote reference, which doesn't seem quite the right way round.

  • Lou Burnard

    Lou Burnard - 2009-11-06
    • status: open --> closed-accepted
  • Syd Bauman

    Syd Bauman - 2010-05-13

    My apologies; I missed this when it was initially closed back in Nov, and just now am noticing it when Kevin mentioned it in private e-mail for a different reason.

    > Syd's example points from the note to the footnote reference, which doesn't
    > seem quite the right way round.

    I agree that it does not seem, at first blush, like the right way round. But it is what the TEI Guidelines explicitly recommended in P2 (6.8.1), P3 (6.8.1), P4 (6.8.1), and P5 (3.8.1). To suggest the reverse -- as has now been codified at r6937 -- seems like a step backwards, a step away from consistency, harmony, and what little interoperability there may be in the TEI universe.

    For years I have told people that it doesn't really matter whether the anchor (typically a content element like <name>, or an attachment flag encoded as <anchor>, <ptr>, or <ref>) points to the note or vice-versa. But since the TEI Guidelines recommend that the <note> point to the <anchor> (or whatever), that is the way they should do it. The logic was that because the TEI Guidelines chose one of these two essentially equivalent methods, everyone would use it, and we'd all share the benefits of doing things the same way.

    Of course, for those who like belts and suspenders, the anchor can also point back to the note. (Using target= or corresp=.)


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks