Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#15 "accept" attribute

Syd Bauman
Andreas Nolda

In linguistics, examples, glosses, or parts thereof are
often prefixed with symbols like "*", "?", "?*", "(?)", "#"
etc., specifying the type or degree of (un)acceptability.
(Unfortunately, there is no consensus as to the
inventory and exact interpretation of these symbols.)

These specifications could be easily represented in TEI
by an optional "accept" attribute on <mentioned>,
<gloss>, and <seg>. The value of the attribute should
directly give the symbol instead of some fixed
meta-value like "yes" or "no".


  • Lou Burnard
    Lou Burnard

    Logged In: YES

    Intriguing suggestion! Would you not also want it for <eg>,
    <q>, <cit> etc? though, e.g. to mark spurious sentences and

    The certainty module provides attributes which might be of
    relevance to this application. Again, if the only purpose of the
    proposal is to affect the rendition of the output, I think the
    REND attribute is a better example.

  • Andreas Nolda
    Andreas Nolda

    Logged In: YES

    The purpose of the proposed "accept" attribute is to encode
    a meta-linguistic acceptability statement on some linguistic
    entity. Of course, an acceptability statement is more than a
    rendition specification of the entity it applies to (but see

    Unfortunately, linguists often record acceptability statements
    by vague and partly undefined marks, though. While "*" is
    usually interpreted as 'unacceptable', the interpretation of
    other notations like "?", "?*", "(?)", "#", "%", "**" etc. are
    rarely specified explicitly.

    Thus, someone encoding or quoting a pre-existing linguistic
    text with undefined acceptability marks has to encode their
    original form--i.e. their original rendition.

    The proposed "accept" attribute could of course be applied
    to additional elements besides <mentioned>, <gloss>, and
    <seg>--namely to all elements representing some linguistic
    entity, including rule-like entities (recall the Generative
    practice of attaching acceptability marks--or, rather,
    grammaticality marks--to rules or parts thereof).

    By the way, the <seg> element may be useful for marking up
    acceptability statements with a restricted scope, for

    <mentioned>Bill loves/<seg accept="'*">love</seg>

  • Syd Bauman
    Syd Bauman

    Logged In: YES

    While the whole idea is new to me, my first reaction is that
    this is a fine idea, and Lou's right, should probably
    include quite a few elements in the class of elements that
    gain this attribute.

    On the other hand, it is worth spending at least a little
    time and effort considering other mechanisms for acheiving
    this goal before settling on one method. Possible examples
    follow, not at all thoroughly thought through, rather just
    thrown out to demonstrate that there are a lot of possibilities.

    * A new <acceptability> empty element which would operate
    much like the current <certainty> (and which might fit well
    into the certainty module) which would bear target=, given=,
    degree=, and desc=. (And rend= for the actual symbol; or
    perhaps the symbol should be the value of degree= if a more
    precise degree is not known.)

    * A new <accept> element which operates somewhat like <sic>,
    but has degree= to indicate the level of (un)acceptability.

    * Using ana= to point to an element that describes the
    elements (un)acceptability.

    It also occurs to me that this problem isn't so dissimilar
    to the problem of wanting to demonstrate how *not* to do
    something by putting incorrect grammer, erroneous computer
    code, or (perhaps the worst for us) invalid XML into an <eg>.

  • Lou Burnard
    Lou Burnard

    Logged In: YES

    We agree that this should be investigated further, and
    probably involving definition of a new attribute class in the
    certainty module.

  • Lou Burnard
    Lou Burnard

    • assigned_to: nobody --> sbauman
    • status: open --> closed
  • Syd Bauman
    Syd Bauman

    • priority: 5 --> 3
    • status: closed --> open
  • Syd Bauman
    Syd Bauman

    • milestone: --> CE
  • Syd Bauman
    Syd Bauman

    Logged In: YES
    Originator: NO

    While we all seem agreed that this is a good idea, it is clear that more thought & effort are needed than we will be able to muster for the 1.0 release of P5. I have therefore opened a ticket (#299) on this subject over at trac (the TEI's new place to keep track of P5 progress), and scheduled it for version 1.1. The Sourceforge version of this ticket can now be closed.

  • Syd Bauman
    Syd Bauman

    • status: open --> closed