I am responding on behalf of the MODS Editorial Committee to the coverInfo proposal of April 3,
A MODS element containing (or pointing to) an image of the front cover of the resource (e.g. a book) described by the MODS record.
And in addition:
- the license applying to the cover, and
- the color grid for the image
imageLicenseURI="http://www.gnu.org/licenses/fdl.txt" colorGrid="fff fff fff fff f00 fff 0f0 0f0 0f0"/>
<colorGrid>fff fff fff fff f00 fff 0f0 0f0 0f0</colorGrid>
Where imageURI is a URI to the cover image, imageLicenseURI is a URI to the license applying to the cover image, and colorGrid is a space separated list of the nine hexadecimal encoded average colors of each of the nine parts of the 3x3 grid covering the cover. (In this example, the top of the cover is white, the bottom is green, and the middle is red with white fields both on the left side and the right side.)
The MODS EC sees the cover image as a separate but related resource. As such, it may be described by a MODS record, represented as a relatedItem. The image license could be represented via accessCondition within the related item.
Currently there is no appropriate 'type' value for the cover image, within the enumerated list of values for the relatedItem 'type' attribute. The MODS EC does not suggest adding a new value; instead, a new attribute, 'otherType', may be defined for relatedItem. For a relatedItem describing a cover image the 'type' attribute would be omitted (it is optional) and a value of 'otherType' supplied. That value would not be included in the schema but could be recommended in the guidelines. It could be,for example, 'coverImage'.
The "otherType" attribute approach matches a practice used in MADS, METS, and EAD.
The MODS EC feels that the color grid is out of scope for a general-use bibliographic element set.