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
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
> -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.
> *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 editor.
> The truly obsessive will also wish to mark (using <am>) the
> full stop which signals that "Mr." is an abbreviation of course.
> 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
> 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!)
Dr James Cummings, [log in to unmask]
Academic IT Services, University of Oxford