Perhaps I misunderstand Lou's point (or the point of @type) but it
does seem to me that there are different types of
regularisations/expansions and we've not yet found an entirely
satisfactory way of distinguishing them in our transcriptions. For
instance, if you regularise 'w<hi rend="superscript">ch</hi>'
as 'which' you're using your own judgment (and knowledge of early
modern conventions) to do the regularising: there's nothing in the
original explicitly telling you that the missing letters are 'hi'. If
you regularise 'u macron' as 'um', you do have an explicit indication
in the original that an m (or possibly an n) is required: in a sense,
you're 'reading' the macron. And a case like 'Phers' with a line over
the top, meaning 'Philosophers', falls somewhere between the two: the
line tells you some letters are omitted but leaves you to work out
what they are. Normalising 'Dot' as 'Dorothy' is something else
again. Are these not objectively different types of regularisation?
John
John Young
The Newton Project
University of Sussex
Quoting Lou Burnard <[log in to unmask]>:
> >
> >> I'm wondering if there's a reason why @type is not allowed on
> >> <choice>, <orig>, or <reg>.
> >>
> >
> > Don't know, but my first guess would be that no one has asked for
> it!
> > :-)
> >
> Actually, someone has already put in a feature request at sourceforge
>
> for a @type attribute on <reg> and at the last Council meeting it was
>
> agreed that this should be provided at the next release.
>
> @type on <orig> or <choice> does not make a lot of sense to me, but
> the
> case has not been argued. You'd usually use @type only if there were
>
> really distinct use cases for a given element -- and surely once
> you've
> said that this is an <orig> or a <choice> there isn't much more to be
>
> said about what it *is*. Of course, as Syd suggests, you might want
> to
> say something additionally descriptive of it (such as its appearance
> in
> the case of <orig>) but that's not what @type is really really for.
>
|
