[tei-council] how about this one?

[Arianna Ciula]

I hope I have read the right draft 
(http://www.tei-c.org/Drafts/facs.odd). Below my comments.


########### introductory statement ###########

'And it may also be complemented by
a trancribed or encoded version of the original source, which may be
linked to the page images.'

I wander whether we could add the case where the objective of the 
encoder is to comment the physical aspect of the source. It doesn't deal 
with a real transcription or more traditional edition, but rather with a 
commentary of codicological/pelograpohycal nature, where the interest is 
still in aligning the explanatory text with the physical samples.

If people think this is a case for using the facsimile module, as i 
hope, then I could provide a concrete example once the draft is approved.

########### direct/indirect use of @facs #######

As other people, I am not sure about the proposed direct an indirect use 
of @facs, but don't want to throw fire so late...so will shut my mouth 
up if it has been agreed upon.

########### dimensions of real objects #########

LB>Is there a negative too many in that sentence, or are you suggesting 
we *should* include the dimensions of the original somewhere? and if so, 
how?

Unless I am misunderstanding the discussion here, I don't think we 
should include any dimension of a real object. We could have images of 
an object that doesn't exist any more.

CW>Yes, lets have dimensions.  As to the details, well... If we have a 
serious of page-scans of the same size, it would surely be enough to 
have one <dimension> child on <facsimile>.  Otherwise, if we have 
<surface> elements to provide for multiple graphics, I'd suggest a 
<dimension> child there as well.

I thought this information should go in the <surrogates> or in general 
in the header.

########## Manual alignment ###########

CD>I think when people are going to do a lot of alignment (such as aligning
each word), then they're more likely to be using some automated tools
anyway, so the extra markup overhead is not an issue. I could be wrong
about that, though. Perhaps you comment on that, Dot?

Well it depends which images you are dealing with. If we are talking 
about manuscripts where not only lines of text overlap but words are not 
properly separated there is no automated process that can help us 
yet...unfortunately...such an OCR would be the dream of any manuscript 
scholar.

######### stand-off ###########

CD>As a distinct benefit, dropping @coords (or @box) from textual elements
also makes for a cleaner separation between the facsimile and the text,
in that the text is not polluted with any "facsimilar" data, and the
facsimile is then "pure" standoff.

Agree!

######### false shortcut for <facsimile> ###########

CD>the simplification would have
come from facsimle graphics always having a <surface/> parent, rather
than sometimes a <surface/> and sometimes a <zone/>
[...]
If so, we could restrict <facsimile> to only contain <surface> elements
(no <graphic>s), each <surface> could be restricted to only contain
<zone> elements, and facsimile <graphic>s would only ever be contained
in <zone> elements, while @facs could be restricted to point only to a
<zone> or (as a concessionary shortcut, for those people who can't
afford <zone> elements) directly to an image file.

Agree.
This would also avoid to have @box in <surface> and would avoid the 
confusion between the <surface> as a conceptual container for a physical 
unit (e.g. a page) and the actual <zone> that may consists of a fragment 
of the source unit or coincide with the chosen unit itself. Things get 
complex though, because I think <zone> would have to allow nesting.
To give a concrete example, since I would argue that, depending on the 
interests of the encoder, the opening of a book could be considered a 
<surface> where the wrapper <zone> could contain the <graphic> for the 
opening and two further <zone>s children (the two pages contained in 
it), we could have:

<facsimile>
<surface xml:id="opening157-158">
   <zone xml:id="op157-158" box="...">
     <graphic url="op157-158.png"/>
     <zone xml:id="157v" box="...">
      <graphic url="157v.png"/>
     </zone>
     <zone xml:id="158r" box="...">
       <graphic url="158r.png"/>
     </zone>
   </zone>
</surface>
</facsimile>

######## Niggle ##########

- 'This might be a sheet of paper or parchment, a face of a monument, a
billboard, a scroll' --> '...a membrane of a scroll' because the whole 
scroll would be the equivalent of a codex or a volume.

Arianna


Lou Burnard wrote:
> Looking around for a nice example for the facsimile section, I have hit 
> on a page in olde frenche which may make it a bit less accessible for 
> some TEI people, but it's nicely printed which should make it a lot more 
> accessible for others.  And it's got bells on it.
> 
> If you share my fondness for this page, who'd like to volunteer to (a) 
> transcribe and mark it up (b) draw boxes on it and give it back ?
> 
> It's at http://www.tei-c.org/Drafts/Bouelles-49r.gif ...  if you like it 
> I will contact the copyright holders.
> 
> I've corrected the draft to say that co-ordinates are counted from top 
> left rather than bottom left, but not made any other revision, pending 
> Dot's comments. So the numbers in the example are Wrong.
> 
> 
> 
> 
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

-- 
Dr Arianna Ciula
Research Associate
Centre for Computing in the Humanities
King's College London
Strand
London WC2R 2LS (UK)
Tel: +44 (0)20 78481945
http://www.kcl.ac.uk/cch