Hi Sebastiaan and TEI,
An interesting article that includes some discussion of the
subject by Matthew Driscoll is available at
http://www.driscoll.dk/docs/Abbreviations.pdf and says all sorts
of sensible things -- I generally agree with its point of view.
What hasn't really been mentioned is that there is at least one
important sub-community in the TEI which uses the markup for
abbreviations and expansions in a very different manner, that is,
the use of the <abbr> element by the EpiDoc community. While I
disagree whole-heartedly with their recommendation of embedding
of <abbr> *inside* <expan>, and think this is a perversion that
even I can't stomach, the great thing about the TEI Guidelines
are that they allow such a wide variety of practice (and
documentation of your particular bizarre kinks in the TEI ODD
Customization file). See
their strange fetish. (Safe for work. ;-) ) And while I disagree
with it, I do support their right to do so in the flexible TEI
framework, and arguments like this do occasionally surface at the
meetings of the TEI Technical Council. (And as an elected
representative, I try to reduce such madness, but am often
out-voted. ;-) )
On 20/07/17 16:58, Sebastiaan Verweij wrote:
> Dear all
> Thanks for your answers and contributions to this v interesting
> discussion. I’ve always, so far, nested <ex> within <expan> but
> more recently started to wonder why, as did Matthew. We will go
> the way of James’s suggestion, of some post-processing to save
> on mark-up time, which is our biggest issue at the moment
> (isn’t it always!). We will also feature manuscript images for
> most, not all, of the texts, so the form of the abbreviation
> should be visible at least, if not hard coded into the
> Toggling between diplomatic, semi-diplomatic, modern (a la
> Folger’s EMMO, for instance) isn’t on our list of immediate
> desirables (once more because of time), though I have a lot of
> sympathy with James below, on catering for future use as much
> as possible.
> Thanks for your thoughts!
> On 20 July 2017 at 10:51:25, James Cummings
> ([log in to unmask]
> <mailto:[log in to unmask]>) wrote:
>> Hi Matthew,
>> 1) No it is not explicitly recommended that <ex> should always be
>> nested inside <expan>, the TEI allows people a lot of flexibility
>> in how they mark abbreviated words, expanded words, abbreviation
>> markers, and expanded text because there are lots of different
>> needs, traditions, and editorial perspectives.
>> 2) I personally always would recommend have the enclosing markup
>> inside <expan>, and indeed inside a <choice> with an <abbr>
>> marking the abbreviated word. e.g. in its fullest form something
>> <abbr>ev<am><g ref="#abbr-er">er</g></am>y</abbr>
>> with the #abbr-er pointing to a <char> or <glyph> in the header.
>> My reason for wanting this is one of future utility of the
>> (openly released) data to do other things and ease of processing.
>> While you can construct most of this programmatically from
>> ev<ex>er</ex>y (and I might have people on projects I'm doing
>> encode it as such initially), it is much easier to offer more to
>> readers having the choice between the <abbr> and <expan>. i.e.
>> you can toggle on and off the abbreviated forms and have the
>> abbreviation marking character there instead (depending on font,
>> etc.). Having at least the orthographic word delimited by
>> <expan>, to me, makes it so much easier to deal with regardless
>> of form of output by grabbing the 'expan' in processing. But one
>> can do this in post processing but that has its limits.
>> In your hypothetical case there is an editorial decision being
>> made: namely that you will show the expanded text but not the
>> form of the abbreviation. That limits, to some degree, the forms
>> of output and what can be done with the data at a later date.
>> That is fine, of course. It is better to have this hypothetical
>> project complete their materials than chase some perfection.
>> I would note that if you have: ev<ex>er</ex>y then
>> programatically getting to <expan>ev<ex>er</ex>y</expan> is
>> fairly straightforward as is getting to:
>> It is knowing what to put in the <am> if you wanted to mark that
>> which is more difficult. (But still solvable for some texts.)
>> I've been thinking about making a general abbreviation-dictionary
>> lookup conversion that would make best guesses for that kind of
>> thing in Latin and Middle English abbreviations.
>> On 20/07/17 09:26, MLH wrote:
>> > Thank you Lou for this clear explanation.
>> > I am still missing a couple of things though (sorry):
>> > -is it recommended that <ex> should always be nested inside
>> > <expan>? (If so, this might be stated more explicitly in the
>> > Guidelines?)
>> > -if it is optional to nest <ex> inside <expan>, what are the
>> > specific benefits one might realise from
>> > `<expan>ev<ex>er</ex>y</expan>` as opposed to `ev<ex>er</ex>y`?
>> > I suppose the answer will depend on the project to some extent,
>> > but say for argument that it is a scholarly edition where it is
>> > sufficient to note the presence of an abbreviation that has
>> > been expanded, not the form of the original abbreviation.
>> > Matthew
>> > *From:* Lou Burnard <[log in to unmask]>
>> > *Sent:* 19 July 2017 18:06
>> > *To:* MLH; [log in to unmask]
>> > *Subject:* Re: to <expan> or not to <expan>
>> > <expan> should contain the whole of a word that has been
>> > expanded. <expan>Mister</expan> when the source says "Mr."
>> > <ex> should contain the bits of an expansion which are not
>> > present in the source text but have been added to it by an
>> > M<ex>iste</ex>r.
>> > The truly obsessive will also wish to mark (using <am>) the
>> > full stop which signals that "Mr." is an abbreviation of
>> > <expan>M<ex>iste</ex>r</expan><am>.</am>
>> > Of course, it might be that (this is for Bertrand) you think
>> > "Mr." is actually an abbreviation for "Monseigneur", in which
>> > case you'd have
>> > <expan>M<ex>onseigneu</ex>r</expan><am>.</am>
>> > Or, if unable to decide, a <choice> containing both, and maybe
>> > also an <abbr> holding the original form just for fun. Though
>> > in that case, where to put the <am> becomes a bit trickier.
>> > On 19/07/17 17:42, MLH wrote:
>> >> Could anyone explain the rationale for combining <ex> and
>> >> <expan> in this way? (for someone not as familiar with the
>> >> transcription module as he probably should be!)
>> >> Thanks,
>> >> Matthew
>> Dr James Cummings, [log in to unmask]
>> Academic IT Services, University of Oxford
Dr James Cummings, [log in to unmask]
Academic IT Services, University of Oxford