Missing documentation: Printed Sources

[riedde]

explanation needed

• <plateNum/> (@doerners)
• <typeDesc/> (@riedde)
• for captureMode see Describing of Audio Sources

[doerners]

First draft for <plateNum>, comments, suggestion, improvements etc. are welcome ;)

The dating of printed sources is a relevant factor for questions of provenance and edition. In the absence of bibliographical information, e.g. on the edition or the year of origin, plate numbers are an essential aid to dating. Though the name might suggest otherwise, plate numbers can be described as designations assigned to a resource by a music publisher which need not necessarily consist of numbers. They are usually printed at the bottom of each page of a musical print and sometimes appear on the title page as well. In MEI any such plate numbers are encoded within the <plateNum> element as plain text. <plateNum> can be captured as a child element to <physDesc> and can additionally be marked within the <titlePage> element if a plate number is visible on the title page as well. If the source is not exactly dated, it is recommended to record the plate number separately within <physDesc> in any case. For instances where any facsimile images are present, the @facs attribute for <plateNum> further allows to link to a designated location of the plate number on any facsimile as the following example illustrates:

<meiHead>
[...]
         <physDesc>
            <plateNum facs="#plateNumber">809</plateNum>
         </physDesc>
[...]
</meiHead>
<music>
[...]
      <facsimile>
         <surface>
            <graphic target="https://api.digitale-sammlungen.de/iiif/image/v2/bsb00110440_00003/full/full/0/default.png"/>
            <zone xml:id="plateNumber" lrx="1400" lry="2800" ulx="1200" uly="2700"/>
         </surface>
      </facsimile>
[...]
</music>

[KristinaRichts]

Hi @doerners , thank you for your suggestion, which I find very good, although I wouldn't say that it is at the coders discretion whether the plate number is captured within the physDesc or the titlePage element, although of course it makes no difference because both pieces of information are enclosed with the plateNum element. The title page can be described in great detail and therefore it is also possible to capture the plate number there. Nevertheless, I think that this information should also be captured again separately as an information element, i.e. one level higher, as a direct child element of physDesc, since it serves as an important tool for dating music prints and should be easy to find (not nested in long title page descriptions).

I wonder if we should not also point out the difference to publisher numbers in this context , which can also help as a dating aid and should be codable. For plate numbers there is this separate element, but not for publisher numbers (or did I miss something?), here you can only encode a num within the publisher element. Some projects attach importance to be able to capture the difference between these two numbers.

What do the others think?

[doerners]

Thank you @KristinaRichts for your comment. I think I understand the problem with the sentence you mentioned and I will think about it some more to hopefully come up with something better. If in the meantime anyone else has a suggestion this would of course be much appreciated as well :)

[KristinaRichts]

How about just writing: "It can be captured as a child element within the physDesc and marked within the titlePage element if it is visible on the title page." ? And perhaps in addition: If the source is not exactly dated, it is recommended to record the plate number separately within the physDesc in any case.

[doerners]

Sounds good to me, thank you @KristinaRichts! I edited the initial draft to incorporate your suggestion.

[gucl-mu]

First, thank you Sophia for your suggestion. It sounds good to me. I agree with Kristina, if there is a plate number on the title page, then it can be marked in the transcription of the title page. But at the same time, the plate number should also be deposited as structured information. I wonder if this should not rather be done in //manifestation/pubStmt. Then you would have <publisher>, <pubPlace> and <plateNum> in one place. (Presumably there is a reason why the plate number is in <physDesc> separately. Unfortunately, I do not know it.
What just came to my mind is that there are many cases where reprints have only exchanged the plate number. Is there a way to specify "old" and "new" plate numbers?

[rettinghaus]

@doerners Thank you for this proposal. May I point out that your example is not valid. @facs should contain one or more URIs to point to something inside the facsimile section.

So you would have in the header:

<physDesc>
    <plateNum facs="#plateNumber">809</plateNum>
</physDesc>

And in the body within facsimile something like:

<zone xml:id="plateNumber">
    <graphic target="https://api.digitale-sammlungen.de/iiif/image/v2/bsb00110440_00003/1200,2700,200,100/full/0/default.png" />
</zone>

I think there is no way to describe within the element directly where the plate number is printed, but one could probably give a hint in its label:

<physDesc>
  <plateNum label="bottom center imprint">J.S.B. I. 204.</plateNum>
</physDesc>

@KristinaRichts Thanks for pointing out the possible difference of the publisher number. It would be worth noting, that often the plate number is identical to the publisher number (like in my example above). Nevertheless a plate number still is something very specific and a "normal" publisher number could go into the more generic <identifier> element. Imagine a music publisher that was taken over by another one at some point, where you then have two editions of a piece by two publishers (with diverging publisher numbers), but the plate number(s) stays the same.

[doerners]

Thank you @gucl-mu and @rettinghaus for your comments!

@gucl-mu: It appears to me that it is possible to repeat the <plateNum> element and encode with the attributes @xml:id as well as @precedes and @follows. Maybe those could be a means to specify "old" and "new" plate numbers? Not sure if that's the best way to go, this was just an idea.

@rettinghaus: Thank you for pointing out the problem with the example. I have to admit that I failed to check the attribute definition and the remark within the element definition itself apparently wasn't clear enough to me in that regard. Should we just replace the example with your encoding?

[ahankinson]

The documentation on zone / graphic / facs is a bit lacking, but the markup that @rettinghaus provided isn't quite "correct", in terms of expectations and in terms of the common practice for facsimile markup. (It is technically "valid" though).

The existing guidelines are here:

https://music-encoding.org/guidelines/dev/content/facsimilesrecordings.html#facsimileElements

Zones are typically expected to be rendered in relation to a full image, and are not intended to be simple segments of the image, but areas of interest on that image. <graphic> is usually given in relation to <surface>.

So my take on @rettinghaus' markup would be more along the lines of:

<surface>
  <graphic target="https://api.digitale-sammlungen.de/iiif/image/v2/bsb00110440_00003/full/full/0/default.png">
  <zone xml:id="plateNumber" lrx="1400" lry="2800" ulx="1200" uly="2700">
</surface>

Note that the IIIF image crop parameters are x,y,w,h, while MEI is ulx,uly,lrx,lry so those co-ordinates would need to be translated: ulx = x; uly = y; lrx = x + w; lry = y + h. The IIIF co-ordinates have been removed from the URL and placed in the zone, and the first full parameter points to the complete image.

Does that make sense? Or did I miss something?

[riedde]

Yes @ahankinson, you're right. I also had the problem in a project I use IIIF and MEI. So the translation is needed, but isn't this a rendering problem? Because If you like to visualize this you need to translate the coordinates and also to modify the URL to get the correct segment. Concerning the code, there is just a target to an image given and a zone that locates an area on that image using pixel cooridnates. So from my view it is okay from its content and the problem depends on the software which will used in a second step.
Maybe I'm missing somthing, but I ask my self if the problem you mentioned is ours ;-) We should keep that in our minds!

[ahankinson]

It's not really a rendering problem. I mean, it is, but it's a bit more complicated than that.

There is a fairly common misunderstanding in how IIIF URLs are to be used with annotations. The example given by Klaus is the "IIIF Image API" style of URL. This is primarily an 'implementation detail' so to speak -- it's the type of URL that enables standardized behaviours across image servers and viewers, allowing for zooming images (so that you can dynamically chop them up and send tile requests). People then naturally extend it to be used as a basis for annotations, but it's not really how it's designed to be used.

The "correct" way to do annotation on a canvas is to use the media fragment syntax. The section on the IIIF Canvas in the Presentation API documentation talks a bit about this.

Annotations on a canvas should use the media fragment syntax, NOT the IIIF Image API syntax, and annotations are always made against the full image. This is because you're supposed to be layering annotations on top of an image -- "painting" on a "canvas" is the Shared Canvas -> Open Annotation -> Web Annotation model. (IIIF started as "Shared Canvas", then that got renamed "Open Annotation" during the development period, and the W3C standard is now officially "Web Annotation")

You can, in your implementation, translate this to the Image API URL to show just that particular region of the image, but you should actually store it (in either Web Annotations or in external documents, like MEI) assuming you're annotating against the full image. This can then be used within a Web Annotation as a target resource.

So in the end, it means that your annotations on an image resource should be serialized as:

https://api.digitale-sammlungen.de/iiif/image/v2/bsb00110440_00003/full/full/0/default.png#xywh=1200,2700,200,100

And not:

https://api.digitale-sammlungen.de/iiif/image/v2/bsb00110440_00003/1200,2700,200,100/full/0/default.png

I think this means that the MEI encoding I provided above is closer to the intent of IIIF. It divides the two concerns. You can also see another benefit of this: In the second URI, technically any change in the image parameters is an entirely different "Resource", in the HTTP sense. This means that, even though the are the same target, the "Web" understands them as being completely different entities.

In the first (correct example), however, the query parameters simply identify a "sub-resource" of the same image. In MEI language this means you can have many different zones on the same surface. In a graph database serialization, you can tie together the same URIs and then serialize just the zones as an additional set of triples against that URI.

If we were to be even more pedantic, technically the MEI surface would actually correspond to the IIIF canvas, and you would use the URIs of those directly, instead of the actual image. But that's even harder, because it's not always possible to tie a canvas to an actual image unless you also parse the full manifest. But I could probably talk for several hours about this. :-D

[riedde]

That clarifys much to me! I also became part of that misunderstanding. But now I can absolutely support the use of the media fragemnt syntax. Thank you for that deep insight!