[tei-council] reduced phrase class proposals

[James Cummings]

Lou Burnard wrote:
> We have the following proposals:
> 1. Move abbr choice and expan out of pPart.edit into a class of their own.
> 2. Make hi the only member of model.hiLike, and put the remaining former
> members into another class model.emphLike
> 3. Separate specDesc and specList from the other members of
> model.specDescLike
> 4. ("arguably") also move code and ident from the current specDescLike
> class into model.emphLike
> 
> My recollection is that time didn't permit us to discuss this in much
> detail in Kyoto, nor to explore the rationale. If we did and I'm just
> being dense, please accept apologies. But ...
> 
> (1) why? the motivation appears to be so that these three pPart.edit
> elements can appear in a new reduced  headerPhraseSeq  but none of the
> others. But I cannot think of any reason why you'd want to indicate a
> choice in the elements for which the said slimmed down headerPhraseSeq
> might be used.  Can anyone come up with a plausible use-case?

Wasn't it that we had pPart.edit which had:
model.pPart.edit = abbr add app choice corr damage del expan orig
      reg restore sic space supplied unclear
and then a combination of Syd and I suggested that we wanted to break these into
semantic groupings like:
model.pPart.edit.choice = choice app
model.pPart.edit.transcribe = add damage del restore space unclear
model.pPart.edit.editorial = abbr corr expan orig reg sic supplied

but that .editorial needed to be broken up more because it made no sense to have
 corr/orig/reg/supplied in header data-like places. I have no use-case for
choice in header-data places though.

> (2) Why? hi is the "generic" version of the others. Again, I presume
> that the motivation is to permit the others (but not hi) within
> headerPhrase . But this seems backwards to me: if you want these things
> at all there, the logical one to keep is hi, not the rest of the motley
> crew, surely?

I assumed it was to allow 'hi' but not the others, but my memory of it is fuzzy.
 Is it that these (distinct, foreign, gloss, term, etc.) are more emph-like than
hi-like?

> (4) I can't make up my mind about this one either.

I'm assuming this was on semantic grounds that code/ident are the same emph-like
things as mentioned, soCalled, foreign, and the like.  Not sure.

-James