Missing documentation: Printed Sources #8
Comments
|
First draft for 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 <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> |
|
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 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 What do the others think? |
|
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 :) |
|
How about just writing: "It can be captured as a child element within the |
|
Sounds good to me, thank you @KristinaRichts! I edited the initial draft to incorporate your suggestion. |
|
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 |
|
@doerners Thank you for this proposal. May I point out that your example is not valid. So you would have in the header: <physDesc>
<plateNum facs="#plateNumber">809</plateNum>
</physDesc>And in the body within <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 |
|
Thank you @gucl-mu and @rettinghaus for your comments! @gucl-mu: It appears to me that it is possible to repeat the @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? |
|
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. 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 Does that make sense? Or did I miss something? |
|
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. |
|
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:
And not:
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 |
|
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! |
|
I edited the initial draft and especially changed the example in light of the comments here – thank you all for the help! I would like to ask everyone to have a look again to check if the updated version might now be suitable for inclusion into the guidelines. |
|
Honestly, I don't think we need the link to |
|
@gucl-mu you're absolutely right regarding Side note: Does anyone know why Personally, I thought it to be important to have an example showing the use of
To me the remark was not clear enough as to how this translates into a specific encoding, because I haven't encountered it before. If someone who is new to MEI wants to encode a plate number, such an example might be useful and maybe clearer than the remark. Regarding the publisher number: Especially @rettinghaus comment lead me to think that this might also be encoded within an |
That's a good point, @doerners . Of course, I think it's okay if we leave With regard to the differentiation between plate number and publisher number, the problem is that there is no separate element for recording the publisher number. Therefore, a description of the preferred encoding of the same will hardly ever be given elsewhere. For this reason, I would suggest that we elegantly build this into the description and perhaps say something like: "Unlike the publisher number, which is captured using an @rettinghaus I think your idea of putting the publisher number in an However, the question of whether the plate number should be captured within
Wouldn't a reprint warrant a new manifestation, which would then include the changed plate number, @gucl-mu? I know, one tends to rather take the "short way" when only the plate number changes ;-) |
|
Here is a reworked proposal for the description of The dating of printed sources is a relevant aspect 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 element as plain text. In this context, it is worth noting that there are cases where the plate number for a particular print is identical to the publisher number of the music publisher responsible for that print. However, in certain circumstances, especially when a music publisher has been taken over by another at some point, it can be the case that two editions of a piece have the same plate number, but the publisher numbers differ because the acquiring publisher has continued to use existing plates. As for the distinction between plate number and publisher number, MEI does not provide a specific element for recording a publisher number. It is recommended to capture each publisher number with the <manifestation>
<pubStmt>
<publisher>
<identifier type="publisher number">123456</identifier>
</publisher>
</pubStmt>
</manifestation>In contrast, any plate number will be encoded within the <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> |
|
First of all, thanks again Sophia, for revising the draft! |
|
@gucl-mu may I ask you to add your name to your profile? We are a small community, and it is always nice to know who we are talking to. Thanks! Laurent |
|
@gucl-mu I agree that the encoding can most definetly be improved and that we should discuss the other points you made! So if anyone comes across a nice (i.e. real) example, please bring it to the next meeting or just drop a comment here :) |
|
As a matter of practice, MEI generally avoids the use of Simple values like Incidentally, using the RDA Registries also let you differentiate between plate and publisher numbers:
So you don't necessarily need to embed (There is also an issue with using |
|
@ahankinson could you give an encoding example of how the encoding of a publisher number might best be realized? That would be helpful, thanks. |
|
"Best" is up to the encoder; I can really only provide additional perspective on the existing tools within MEI that I don't see in evidence in your example. But, to take your example from above, if all you wanted to do was capture the publisher number, then it might look something like this: That is, there is no need to embed this in the This is in response to your observation that there is "no" publisher number in MEI -- it's true that there is no specific element for it, like plate numbers, but that doesn't necessarily mean you can't capture it. You might even choose to not use |
|
Personally I think it is counterintuitive to use label instead of type. In my understanding, label means the name we give to an object, type, on the other hand, specifies the nature of the object. What would a correct encoding using type instead of label look like? Furthermore, wouldn't it be better to nest the publisher number within publisher to designate to which publisher this number is assigned? I mean, yes, the source may be the object from which we recognize the publisher number but isn't it rather primarily an identifier for the corporate body than the source? Since, according to my example, it is all encoded at the manifestation level anyway, the connection to the manifestation is established, is it not? |
That's the thing -- there is no "correct" encoding using In other words, your example was "correct" in the same way that doing
That's what my example gave -- You can remove DOIs are primarily about resolving content to a specific representation. The RDA Vocabularies are about unique identifiers for shared concepts: If I see that given URI, I know that it unambiguously refers to the concept of a publisher's number. More importantly, if other people find my data and want to parse it, then they can unambiguously look up what that concept means. If we're just doing "classification by string" then it's a lot harder to share data. You might use the string "publisher number"; someone else might use "pubnum"; someone else might be "publisher_identifier", etc. In heterogenous datasets, the variations of the different concepts and methods of classifying stuff is what really makes data non-interoperable. So shared vocabularies are really helpful.
Sure -- I mentioned that you can embed it in there if you want; I was mostly going on your encoding where there was no other information about publishers given. There, it seemed that the only reason to scope it inside of a |
|
Thanks to all for the comments here and to everyone who attended out last IG meeting. I have reworked the draft for the description of Comments and also critique are welcome! However, I'd like to make a little request: If there is anything you'd like to improve, please provide an actual suggestion on how to phrase or encode something differently, rather than just pointing out what could be problematic. I feel this would especially facilitate a faster improvement process and make it easier to incorporate any changes. And of course credit will be given where credit is due ;) Here the reworked draft: The dating of printed sources is a relevant aspect 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 (only) 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 In this context, it is worth noting that there are cases where the plate number for a particular print is identical to the publisher number assigned by the music publisher responsible for that print. However, in certain circumstances, especially when a music publisher has been taken over by another at some point, it can happen that two editions of a piece have the same plate number, but the publisher numbers differ because the acquiring publisher has continued to use existing plates. As for the distinction between plate number and publisher number, MEI does not provide a specific element for recording a publisher number. It is recommended to capture each publisher number with the <manifestation>
<pubStmt>
<publisher>
<corpName auth="GND" auth.uri="https://d-nb.info/gnd/2045143-X">Universal Edition</corpName>
<identifier type="publisher_number" auth="RDA" auth.uri="http://rdaregistry.info/Elements/m/P30276">1967</identifier>
</publisher>
</pubStmt>
<physDesc>
<plateNum>1913</plateNum>
</physDesc>
</manifestation> |
The documentation for
(Here's me pointing out a problem again!) There are two problems with splitting the values across
I don't actually see much benefit from splitting the full identifier between
The same would follow for
Two other comments:
On the one hand, it's slightly redundant. On the other, however, it does allow for the unification of identifier capture, which would make parsing and understanding the content of an MEI file easier, particularly for metadata systems. Since |
|
One other thing that occurs to me about splitting If they are split, you're never really sure if the So making it "best practice" to always include the full identifier is probably easier for everyone. |
|
Thanks @ahankinson! I edited the draft so that the URIs are not splitted anymore. Question: If it is better to include the full URIs rather than splitting the values why does MEI offer
<plateNum>
<identifier type="plate_number" auth="RDA" auth.uri="http://rdaregistry.info/Elements/m/P30066">1913</identifier>
</plateNum>Regarding 1.: Regarding 2.: In general I'm in favour of a unification of identifier capture. However, nesting
Idea 1 would be the question why there if |
I'm not sure. I suspect it's needed if you only have an identifier that isn't in URI form -- the MARC Codes for Organizations is one such example that I've come across, where it has an "Authority" and a "value" but no canonical URI form. So for example, <corpName auth="MCO" codedval="QMMMDM" auth.uri="https://www.loc.gov/marc/organizations/">Marvin Duchow Music Library</corpName>(I'm totally making this up -- it shouldn't be used as an actual example of proper encoding!) In this case you can't just stick the Another example might be where the URI and the value can differ. So, for example, the same library in RISM has a sigla of <corpName auth="rism" codedval="CDN-Mm" auth.uri="https://rism.online/institutions/30000472">Marvin Duchow Music Library</corpName>In this case the
That's what I was thinking. If you want to illustrate something specific, it's probably better to omit the things you're not prepared to describe. That way people don't come away wondering why As for the
I don't think you should hold off. MEI has a lot of options, and about twenty different valid ways to do the same thing. I think it would be best to narrow it down to a single reasonable recommendation using the available elements, instead of waiting for the perfect schema to emerge. |
|
This example from @ahankinson leads the reader/computer to believe that they can find more information about the number <identifier label="Publisher Number" auth.uri="http://rdaregistry.info/Elements/m/P30065">123456</identifier>The MEI way to describe an elements relation to another standard would be using <identifier label="Publisher Number" analog="rda:P30065">123456</identifier>Furthermore I think Saying this, I would propose to change the example given above slightly into: <manifestation>
<pubStmt>
<publisher>
<corpName auth="GND" auth.uri="https://d-nb.info/gnd/2045143-X">Universal Edition</corpName>
</publisher>
<identifier type="publisher_number" analog="rda:P30276">1967</identifier>
</pubStmt>
<physDesc>
<plateNum analog="rda:P30066">1913</plateNum>
</physDesc>
</manifestation> |
@rettinghaus I'm not sure that's entirely correct. The documentation for
(emphasis mine). That says to me that it can be either an authority for the element OR for the content of the element. In the specific case of identifier, I think this would mean that it would define the identifier as being one of a publisher or plate number. Using Further, looking at the
From https://music-encoding.org/guidelines/dev/attribute-classes/att.bibl.html This suggests to me that the |
|
Thanks Klaus and Andrew for the explanations about |
riedde
changed the title
|
Since the next IG meeting is close, here a new reworked draft for the description of The dating of printed sources is a relevant aspect 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 (only) of numbers. When present, 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 can be encoded within the
|
Co-authored-by @music-encoding/ig-metadata Co-authored-by @doerners relates to music-encoding/metadata-ig#8
explanation needed
<plateNum/>(@doerners)<typeDesc/>(@riedde)The text was updated successfully, but these errors were encountered: