[tei-council] oversimplification: <measure> isn't measured

[Arianna Ciula]

Syd Bauman wrote:
> SB> In Berlin the TEI Council requested the creation of a new element,
> SB> <measureGrp>, which would replace the special-purpose <dimensions>
> SB> element. Was part of the point of this exercise to eliminate the
> SB> special-purpose <height>, <width>, and <depth> as well, using (e.g.)
> SB> <measure type="height"> or some such instead?
> 
> LB> No, I don't think so. 
> 
> Check. Anyone else have a useful recollection on this?

This is what I have in my notes from Berlin:
=============================
Manuscript Description.

DOD: use of extent/dimensions compared to measure (to be constrained 
within this chapter); LB: chapter that lack integration with the class 
model; redefinition of height and width (as special cases of measure) 
and dimensions could be a grouped measure (all in measureLike class). We 
would have particular constraints for the manuscript module (e.g. Always 
height and width within the measurement group).
==============================

DOD: Dan
LB: Lou

not sure it helps...

Arianna
> 
> 
> LB> The specific elements are permitted as children of <measureGrp>
> LB> as an alternation to text.
> 
> Yes, right, this is currently the case, but I do not think text
> should be permissible in the content of <measureGrp>. I cannot come
> up with a good reason to use use an element that groups measurements
> with anything other than elements from model.measureLike, let alone
> plain text, as its content. Can you provide an example of how this is
> useful? (But note that I am explicitly saying the in the simple case
> of
>     <measureGrp> 7 x 12 </measureGrp>
> it is not useful.)
> 
> 
> LB> As I remember the discussion, we recognises that most
> LB> institutions would always supply dimensions in their own specific
> LB> sequence, and might not want therefore to tag the height etc.
> LB> explicitly. 
> 
> I don't remember any such conclusion, and don't think it is a good
> reason to violate the principle of what a <*Grp> element is. Is it
> really that tough to use 
>   <height>7</height> <width>12</width>
> instead of
>   7x12
> ? Perhaps I'm being a holier-than-thou bigot here, but I don't see
> anything wrong with telling those institutions who always do supply
> dimensions in their own specific order "too bad, you have to
> explicitly say which is which anyway" (at least, if you want to use
> <measureGrp>). 
> 
> 
> LB> Compare the <geo> element, which just knows that you give lat and
> LB> long in that order.
> 
> Indeed. As far as I can tell, <geo> is underspecified[1], but even it
> gives a default order: latitude then longitude. The imagined use of
> <measureGrp> here doesn't even specify a default order, so that if I
> come across "7x12" I don't know which is height and which is width,
> or if one of them is actually depth. In manuscript description these
> terms are defined, and the difference matters, no?
> 
> 
> SB> ... <measure> ... has traded in its quantity= attribute for an
> SB> extent= attribute.
> 
> LB> I agree "extent" is a slightly strange name for this: how about
> LB> @count?
> 
> Well, count= is certainly better than extent=. But it is really only
> correct for measurements of countable things like "1 dozen roses"; it
> still isn't quite right for uncountables, like "66.95 mL", or even
> "12 in". I think the right attribute name is "quantity".
> 
> The Brown STG <measure> element upon which the P5 0.5 <measure>
> element was based used count= -- one of the few improvements we made
> was to change the name of this attribute to quantity=. It was a good
> idea then, and I still think it is.
> 
> 
> SB> ... the "suggested values include" list for unit= has lost all
> SB> the suggested values that don't make sense when measuring a page.
> 
> LB> The international standard is referenced, and I've certainly no
> LB> objection to adding a few more examples taken from it
> 
> While I think a few more examples is far better than none, what I
> don't understand is why not all of them? Why make a poor user go off
> and read SI or NIST documentation, rather than just give her a nearly
> comprehensive list of values? When she goes to enter a unit=, oXygen
> would pop up the list with its glosses and descriptions, and she can
> easily discover that she should use "kg", not "Kg" for kilograms, and
> "in", not "inch" for inches.
> 
> 
> SB> * move <measure> back to att.measurement
> 
> LB> Cant see anything to be gained by doing this, other than the
> LB> confusion of now having two classes with the same meaning
> 
> But my point is that they don't have the same meaning. One is general
> purpose for which commodity= and a long "semi" list of possible
> values makes sense, but for which scope= is at least underspecified,
> if it makes sense at all; the other is very special-purpose, for
> which commodity= is always already known, scope= makes sense, and the
> list of possible values should be quite limited.
> 
> This is a case where splitting is more helpful to the end user than
> lumping. 
> 
> 
> SB> * remove text from content of <measureGrp>? (if it seems important,
> SB>   put model.pLike in?)
> 
> LB> Not a good idea in my view, for reasons given above
> 
> I disagree. I cannot see any reason why
> 
>   136 folios:
>   <measureGrp> 280 x 190 </measureGrp>.
>   Twenty-three quires of eight ...
> 
> is significantly superior to
> 
>   136 folios: 280 x 190.
>   Twenty-three quires of eight ...
> 
> If one is going to bother putting a <measureGrp> in, then why not
> make it useful for processing:
> 
>   136 folios:
>   <measureGrp> 
>     <height unit="mm">280</height>
>     <width unit="mm">190</width>
>   </measureGrp>.
>   Twenty-three quires of eight ...
> 
> 
> Notes
> -----
> [1] Many, if not most, users will want to know what syntax to use for
>     expressing latitude and longitude. WGS 84, as far as I can tell,
>     provides no guidance here at all. Are they expressed as degrees,
>     minutes, and seconds, or as decimal degrees? With compass
>     direction, or using signed values? What symbols, if any, are used
>     to indicate the unit(s)? What separates the latitude from the
>     longitude? But for that matter, these TEI guys use "2" to mean
>     "female", maybe they want longitude expressed in radians (but if
>     so, signed values < pi or unsigned < 2*pi? :-)
>     While I'm at it, I noticed that <geoDecl> is a member of
>     att.declarable, but that <geo> is not a member of att.declaring;
>     is the presumption that all of the <geo>s in a given <div> will
>     always use the same <geoDecl>?
> 
> _______________________________________________
> 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