#449 am and ex should claim membership of att.typed

GREEN
closed-accepted
None
1(low)
2013-06-17
2013-03-27
No
I believe that <am> and <ex> elements should claim membership of att.typed because one can have <choice><am>...</am><ex>...</ex></choice> and have perfectly reasonable causes to want to classify the type of abbreviation marker or the type of expanded text.  (Well, more so with abbreviation markers).  <abbr> and <expan> get types and if we can use <am> and <ex> without it then being able to @type these would be useful.

Related

Feature Requests: #449

Discussion

  • BODARD Gabriel

    BODARD Gabriel - 2013-03-27

    Do you have an example of this in use? That would make this request more convincing, imho.

     
  • James Cummings

    James Cummings - 2013-03-27

    In fact,I do.

    I'm converting some Great Domesday Book markup of someone's own invention and one thing they do is classify the type of abbreviation markers (in 16 different types that I've found so far). They have not, in their markup, wrapped the whole word so I don't want to use abbr to do this (which I prefer to retain for when marking an abbreviated word, perhaps with am's inside it). One of the things they are interested in doing is later analysing the types of abbreviations and their frequency, etc.

    So they have the equivalent of:

     fuer<am type="0">unt</am> <am type="7">et</am> dim<am type="1">idiae</am>
    

    which I obviously want to convert to using <choice> but want to retain their form of classification. To be specific these @type values are glossed as not just being the form of the <am> but the nature/intent of the abbreviation. (So something might be marked as an abbreviation through a bar over some letters, but this may have different intents in different places.)

     
  • Lou Burnard

    Lou Burnard - 2013-03-27

    If the @type values refer not to the specific <am> you want to attach
    them to, but to the in which that <am> features, this is surely a
    strong argument AGAINST the proposal? If you want to say that the
    "intent" of this <am> in this context is "x" then you need to mark the
    context. which is what is for.

    On 27/03/13 17:01, James Cummings wrote:

    In fact,I do.

    I'm converting some Great Domesday Book markup of someone's own
    invention and one thing they do is classify the type of abbreviation
    markers (in 16 different types that I've found so far). They have not,
    in their markup, wrapped the whole word so I don't want to use abbr to
    do this (which I prefer to retain for when marking an abbreviated
    word, perhaps with am's inside it). One of the things they are
    interested in doing is later analysing the types of abbreviations and
    their frequency, etc.

    So they have the equivalent of:

    fuer<am type="0">unt</am> <am type="7">et</am> dim<am type="1">idiae</am>

    which I obviously want to convert to using <choice> but want to retain
    their form of classification. To be specific these @type values are
    glossed as not just being the form of the <am> but the nature/intent
    of the abbreviation. (So something might be marked as an abbreviation
    through a bar over some letters, but this may have different intents
    in different places.)


    [feature-requests:#449]
    http://sourceforge.net/p/tei/feature-requests/449/ am and ex should
    claim membership of att.typed

    Status: open
    Created: Wed Mar 27, 2013 04:32 PM UTC by James Cummings
    Last Updated: Wed Mar 27, 2013 04:43 PM UTC
    Owner: nobody

    I believe that<am> and<ex> elements should claim membership of att.typed because one can have<choice><am>...</am><ex>...</ex></choice> and have perfectly reasonable causes to want to classify the type of abbreviation marker or the type of expanded text. (Well, more so with abbreviation markers). and<expan> get types and if we can use<am> and<ex> without it then being able to @type these would be useful.

    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/tei/feature-requests/449/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Feature Requests: #449

    • James Cummings

      James Cummings - 2013-03-28
      So you are saying in this case that I need to mark the <abbr> but I'm reluctant to because I editorially wish to treat <abbr> as something that marks an abbreviated word as a whole. The Guidelines say "The content of the <abbr> element should usually include the whole of the abbreviated word" and I agree with that. The @type values DOES refer to the specific thing not something (is there a word missing there?) in which it features. It is the nature/intent implied by the abbreviation marker that the encoder has captured in his own markup. There is only an <am> here no <abbr> and I think it would be wrong to do 'fuer<choice><abbr type="0"><am>[unt-abbreviation-character]</am></abbr><expan><ex>unt</ex></expan></choice> and the Guidelines mid-way through http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHAB clearly suggest I can use just <am> or <ex> inside a <choice>.
      
       
  • Lou Burnard

    Lou Burnard - 2013-03-30

    Wow, these thread really demonstrates nicely why this new ticket formatting facility is a mixed blessing!

     
  • Lou Burnard

    Lou Burnard - 2013-03-30

    It wasn't clear from your first post whether it's a different type of
    "unt-abbreviation-character" or a different use for the same
    "unt-abbreviation-character". If it's the former, then I would agree
    that @type on <am> might make sense; if it's the latter then I
    wouldn't. A superscript "r" is a superscript "r", whether it signals
    "onsieur" or "ister".

    On 28/03/13 10:06, James Cummings wrote:

    So you are saying in this case that I need to mark the but I'm
    reluctant to because I editorially wish to treat as something
    that marks an abbreviated word as a whole. The Guidelines say "The
    content of the element should usually include the whole of the
    abbreviated word" and I agree with that. The @type values DOES refer
    to the specific thing not something (is there a word missing there?)
    in which it features. It is the nature/intent implied by the
    abbreviation marker that the encoder has captured in his own markup.
    There is only an <am> here no and I think it would be wrong to
    do 'fuer<choice><abbr

    type="0"><am>[unt-abbreviation-character]</am><expan><ex>unt</ex></expan></choice>
    and the Guidelines mid-way through
    http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHAB
    clearly suggest I can use just <am> or <ex> inside a <choice>.


    [feature-requests:#449]
    http://sourceforge.net/p/tei/feature-requests/449/ am and ex should
    claim membership of att.typed

    Status: open Created: Wed Mar 27, 2013 04:32 PM UTC by James
    Cummings Last Updated: Wed Mar 27, 2013 05:01 PM UTC Owner:
    nobody

    I believe that <am> and <ex> elements should claim membership of
    att.typed because one can have
    <choice><am>...</am><ex>...</ex></choice> and have perfectly
    reasonable causes to want to classify the type of abbreviation marker
    or the type of expanded text. (Well, more so with abbreviation
    markers). and <expan> get types and if we can use <am> and
    <ex> without it then being able to @type these would be useful.


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/tei/feature-requests/449/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Feature Requests: #449

  • James Cummings

    James Cummings - 2013-04-11
    • assigned_to: James Cummings
    • Group: AMBER --> GREEN
     
  • James Cummings

    James Cummings - 2013-04-11

    Council face-to-face 2013-04 decided to implement for 'am'.

     
  • James Cummings

    James Cummings - 2013-06-17
    • status: open --> closed-accepted
    • Priority: 5 --> 1(low)
     
  • James Cummings

    James Cummings - 2013-06-17

    Implemented at revision 12263