[tei-council] FW: Further update on PH

[Conal Tuohy]

Sebastian Rahtz wrote:
> one thing which bothers me still, which Lou and I spent a while
> on today without reaching consensus, is how to document
> <zone> and <surface>. eg, how do I say
> 
>  - this zone is a closeup of the  messy changes in the margin

Well ... the zone could be linked via @facs from the messy changes themselves, but if you want to attach a description "Messy changes in the margin" then some kind of note or desc is called for I guess.

>  - this <graphic> is colour, this <graphic> is infrared (both are of
>    same zone and surface)

James (I think) mentioned the link to <surrogates> and I think this might be a good way to handle it (though I guess it requires the Manuscript Description module). Alternatively, one could use @type. 

>  - this <graphic>/ <zone> was taken in 1920, this other pair
>    was taken in 1960 after the fire
>  - this picture is an oblique shot of the surface

Obliquity is an issue I've actually given some thought to. The current zone markup doesn't handle it (and this is evidenced in the gravestone example, where the perspectives of the 2 graphics are slightly different). However, the existing schema could be extended to handle perspective. Personally I'd be happy if we left this until v1.1, because I think it's a less common case that is less urgent than the commonest case, which is that documents are imaged from directly overhead, often in a flatbed scanner, with little or no perspective effects.

The reason it's not handled at the moment is because of the way that the graphics are "projected" onto the coordinate space of the physical surface. The projection is defined by a "bounding box" which is assumed to be rectangular in shape, hence the bounding box is specified by giving the coordinates of only 2 of its corners. However, particularly with photographs of large surfaces, the appropriate bounding box is sometimes not rectangular, and in the case of an oblique photo it would be approximately trapezoidal or more accurately an irregular quadrilateral. In such a case, the bounding box would have to be specified by giving the coordinates of all 4 corners, not just 2. 

So I think if we were to define att.coordinated to include @ulx, @uly, @lrx, and @lry then we would only need to add @urx, @ury, @llx, and @lly in order to handle different perspectives.

> do others recognise any of these scenarios? Lou and I imagined
> how we would do the 1920/1960 one by using standoff links to
> <bibl> records, but the others?

I agree, and I think @decls links to teiHeader//bibl records would handle this case.

> at the least, I'd be happier if <surface> and <zone> had
> <desc> children or the like.

I agree that this could be useful. Martin Holmes and his IMT users will want to attach notes to their zones, too.