Closed thea-m closed 4 years ago
The addition of images is possible, documented in the guidelines and especially welcome! I will review the PR. My main concern remains that the language of these encoding guidelines does not make it hard to encode to favour cataloguing issues which are no doubt relevant but not the main focus of the GL. We need to find a good balance, which is not easy, but we can achieve together. I would not want to have to check for regression in this respect, due to rewriting instead of editing, but I will do it if this is where it moved to. Completing the work by adding the images before the PR would be very helpful.
Sorry, Dorothea, I cannot find it; "you can find this branch by going on "current branch" in GitHub desktop and either scrolling down until you see the branch called "collation", or typing collation in the filter field, it should then be listed immediately" - the instruction brings me to nothing that is similar to "collation guidelines". Any other way to get to it?
@DenisNosnitsin1970 I have sent you instructions with screenshots on skype, let me know if this helps.
Thank you @PietroLiuzzo!
Regarding the images: there are "only" instructions in the guidelines on how to add IIIF images from the web. The ones we would like to add here are schematic figures produced for this purpose by Denis, and which are currently available to me in a word document.
Regarding the rest: I am afraid I do not quite understand what you mean.
My main concern remains that the language of these encoding guidelines does not make it hard to encode to favour cataloguing issues which are no doubt relevant but not the main focus of the GL.
Do you mean that the proposed edits make it hard to find information on how to encode crucial information, because the focus is taken away from descriptions concerning purely encoding and directed towards more general cataloguing instructions? We might have slighly diverging understanding of the aim of these guidelines. For me, they are indeed encoding guidelines, because they develop how anything in BM can be encoded. Since we are encoding content and cataloguing, the encoding and the content cannot be strictly separated - especially since we do not have a separate set of cataloguing guidelines. I would, as a user, hope to find in the guidelines detailed instructions on how to encode the things I encounter during my work. This includes quire structure. We have all repeated often that the guidelines present what can be done, not was has to be done in every case. It was for me impossible at the beginning of my work to understand from the guidelines how to encode quire structure, because for example the numeration of the leaves was not clear to me. I see no reason to separate such explanations from encoding instructions. Maybe we have a different understanding. Or maybe I missunderstood you completely. I also do not really understand what you mean by regression. In any case, I am always completely in favour of a good balance of anything!
What I was referring to in my concern was a case like this
we now have
<collation>↗ can be used to give textual information about how the leaves are arranged using a <list>↗ of <item>↗ elements.
and the word document which was shared with me, and I opened only on its first page has the following, which was also in the branch at some point not worth investigating
The main elements that should be used for encoding information on the structure of the textblock are <collation>↗ and <list>↗ of <item>↗ (example 1).
This formulation is for guiding an encoder very confused and partially incorrect, and I would avoid this kind of rewording. The collation branch now has
Information on the quire structure is encoded in <collation>↗ with a <list>↗ of <item>↗ elements for each quire.
This is instead an improvement on the previous text, and it is fine. If the reworking from the document into the branch for this PR is consistently done in this way, and not as in the document then it will be easy to review and merge.
As for the images, if there are no new versions, I will upload them to the server and provide a link to use following the guidelines for linking via IIIF. Are those in the document still fine or are there new versions?
let me know when I should look at the collation branch if you want me to look before the PR and add those links directly.
Thank you! The images are identical, I added the reference to the figure in Denis' document in the record. If you could add the links, it would be very useful.
Include the images of stubs:
where should these go?
In the commit above to the branch I added the links to the images, the other ones can be added similarly, I have downloaded them as they appear here and named them 4 to 7.
please note that they will need a caption inside <desc>
thanks!
Thank you all for the extremely constructive work on this. I think we can move this discussion to a pull request.
I have added a comment in#88. Are both dedicated to the same?
Yes, exactly. Thank you! We can keep the discussio now in https://github.com/BetaMasaheft/guidelines/pull/88
I have continued to edit the collation page in the guidelines with the very thorough descriptions given by @DenisNosnitsin1970 . Thank you, it must have been a lot of work! I believe that nothing new has been added on the encoding itself, rather the existing practice has been made explicit and explained for anyone encoding quire structures for the first time. You can find these edits all in the "collation" branch in the guidelines repo (you can find this branch by going on "current branch" in GitHub desktop and either scrolling down until you see the branch called "collation", or typing collation in the filter field, it should then be listed immediately). I have commented out some comments and also stated the places in the page where an addition of images would be helpful, but I don't know if this is possible technically. Most of the examples are now not taken from real records, which is of course not ideal. Since the entire page is very didactic in character I find it justifiable, because they are really very clear and illustrating. From my point of view, this is ready to be pull requested (and to be continually improved in the future), but there was a desire for further communication so let's communicate :) @PietroLiuzzo @DenisNosnitsin1970