[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