[tei-council] my notes in creating data-like subset of model.phrase
James Cummings
James.Cummings at computing-services.oxford.ac.uk
Thu May 25 02:01:48 EDT 2006
Syd Bauman wrote:
Just some thoughts on this from a semantic nature:
> model.graphicLike = binaryObject eg egXML formula graphic
Ugh. Since eg|egXML certainly aren't 'graphicLike' semantically, is
there a benefit of breaking this into two classes? i.e.
model.graphicLike = binaryObject formula graphic
model.egLike = eg egXML
Surely there must be somewhere we'd want to use eg|egXML where we
wouldn't want to use graphics. (or am I misunderstanding?)
> model.pPart.edit = abbr add app choice corr damage del expan orig
> reg restore sic space supplied unclear
>
> becomes:
>
> model.tPart.edit =
> model.pPart.edit.??? = abbr choice expan
> model.pPart.edit.transcribe = add app corr damage del orig reg restore sic space supplied unclear
App, in some ways, is a specialised form of choice. Wouldn't it make
sense for them to go together? likewise, abbr/expan are the same
kinda thing as corr/sic ... so this division doesn't really make sense
to me.
model.pPart.edit.choice = choice app
model.pPart.edit.transcribe = add abbr corr damage del expan orig reg
restore sic space supplied unclear
I suppose this could be split upon whether it is describing something
in the original or editorial introduction
model.pPart.edit.transcribe = add damage del restore space unclear
model.pPart.edit.editorial = abbr corr expan orig reg sic supplied
> arguably <code> and <ident> should be in model.emphLike instead.
I'd second this.
> [1] An argument could be made to divide model.graphicLike so that
> <binaryObject> and perhaps <formula> and <graphic> were not in
> model.headerPhrase.
I'd agree with that argument, I think.
Certainly an overall improvement,
-James
More information about the tei-council
mailing list