Nv 2024 issue 2630 #154
Nv 2024 issue 2630 #154
Conversation
pages/Manuscripts.xml
Outdated
| @@ -69,6 +69,17 @@ type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> | |||
| <p>It can be that you find out the same manuscript is present under 2 identifiers.</p> | |||
| <p>You can fix this by merging the two records in one and deleting the one with less information. Remember when doing this to check for references to the id which will go missing, and update them to point to the other identifier.</p> | |||
| </div> | |||
| <div type="level2"> | |||
| <head>Differenciating between various levels of description</head> | |||
| <p>Following <ref target="https://github.com/BetaMasaheft/Documentation/issues/2700" | |||
There was a problem hiding this comment.
Including references to issues is rarely done in the guidelines so far. On the one hand, this is very helpful and improves transparency, on the other, it makes the text somewhat more complex and longer. Maybe a compromise could be to move the reference into paranthesis at the end of the paragraph ("(see issue XX)"), so that it can be skipped easier when skimming the guidelines.
There was a problem hiding this comment.
Link to the issue must be included in the description of the pull request, then it can always be found (not as title but as a link, or several links - you can edit the very first message in this pull request)
For better documentation it is always better to have each issue clearly linked to each change in github history, so it is not ideal to have several files for several issues in one pull request (we are not going to change it now, but for the future).
Please remove the links to the issues from the guidelines, this is not something we want.
There was a problem hiding this comment.
@eu-genia @thea-m I have followed the example for issue 368 (BetaMasaheft/Documentation#368)
in https://betamasaheft.eu/Guidelines/?id=manuscripts
Is it a different case or should I change that part too?
pages/Manuscripts.xml
Outdated
| <p>Following <ref target="https://github.com/BetaMasaheft/Documentation/issues/2700" | ||
| >issue 2700</ref>, to mark a rudimentary description as "stub" (if the cataloguer wants others consider it as "stub"), one needs to | ||
| write the word "stub" anywhere in the change history. When the record has stopped being a stub as it has been developed further then in the first change line the word stub must replaced with something like initial version or anything else. | ||
| </p> |
There was a problem hiding this comment.
quotations marks around "initial version", I think
pages/Manuscripts.xml
Outdated
| <head>Differenciating between various levels of description</head> | ||
| <p>Following <ref target="https://github.com/BetaMasaheft/Documentation/issues/2700" | ||
| >issue 2700</ref>, to mark a rudimentary description as "stub" (if the cataloguer wants others consider it as "stub"), one needs to | ||
| write the word "stub" anywhere in the change history. When the record has stopped being a stub as it has been developed further then in the first change line the word stub must replaced with something like initial version or anything else. |
There was a problem hiding this comment.
I think it would be nice to include as an example the complete <revisionDesc> of a file that followed this process (as two <egXML xmlns="http://www.tei-c.org/ns/Examples"> elements). The original one using "stub" could be included after "one needs to write the word "stub" anywhere in the change history.", and the revised one after "initial version or anything else". ANLcr1 is a real example that comes to my mind just because I was involved, any other file would work as well.
pages/Manuscripts.xml
Outdated
| >issue 2700</ref>, to mark a rudimentary description as "stub" (if the cataloguer wants others consider it as "stub"), one needs to | ||
| write the word "stub" anywhere in the change history. When the record has stopped being a stub as it has been developed further then in the first change line the word stub must replaced with something like initial version or anything else. | ||
| </p> | ||
| <p>On the opposite, following <ref target="https://github.com/BetaMasaheft/Documentation/issues/2630">issue |
There was a problem hiding this comment.
I would leave out "on the opposite", because there is no argumentation here, just a description of two different cases
| <p>On the opposite, following <ref target="https://github.com/BetaMasaheft/Documentation/issues/2630">issue | ||
| 2630</ref>, in cases of enriching a historical catalogue description, such as verifying images or | ||
| adding new information, one can acknowledge this using <ptr target="bm:BmWebsite"/>, see the respective paragraph in <ref target="bibliographic-references" | ||
| >Bibliographic References</ref></p> |
There was a problem hiding this comment.
I think here as well a real example from a record would be helpful
There was a problem hiding this comment.
Here I refer to a different page óf the guidelines. Should I rather repeat everything?
There was a problem hiding this comment.
ah, I missed this, then it should be enough like this!
pages/workHeader.xml
Outdated
| <p>As stated in <ref target="https://github.com/BetaMasaheft/Documentation/issues/714" | ||
| >issue 714</ref>, we always use <gi>witness</gi> for those manuscripts which are | ||
| used for the edition we are going to (or could potentially) provide in the <tag>div | ||
| type='edition'</tag>, if one click 'text' in the upper menu. All manuscript |
There was a problem hiding this comment.
I think I would delete "if one click 'text' in the upper menu", because this is secondary.
pages/workHeader.xml
Outdated
| target="https://github.com/BetaMasaheft/Documentation/issues/2699">issue | ||
| 2699</ref>, if someone wants to list further records containing this work, an | ||
| acceptable practice is to list otherwise invisible manuscripts as <gi>witness</gi> as well. | ||
| Since identification of witnesses is part of the research, whoever has done it should be acknowledge in the <gi>note</gi> and bibliographic references (if available).</p> |
| acceptable practice is to list otherwise invisible manuscripts as <gi>witness</gi> as well. | ||
| Since identification of witnesses is part of the research, whoever has done it should be acknowledge in the <gi>note</gi> and bibliographic references (if available).</p> | ||
| <p>If someone decides to list manuscripts that were neither used in the edition nor fall in the category of stubs, for the sake of clarity, using the <gi>note</gi>, one can state what is its specific relevance.</p> | ||
| <egXML xmlns="http://www.tei-c.org/ns/Examples"> |
There was a problem hiding this comment.
Is there an example of this use of <note> that could be included in the following example?
There was a problem hiding this comment.
There is no for the moment. Should I create a fake one or wait until I create a real one?
There was a problem hiding this comment.
Then maybe better just leave it, I think
pages/workHeader.xml
Outdated
| <p>Please note that the list of manuscripts containing a work shown in the application | ||
| and the list of witnesses used for an edition are two different things. The first | ||
| picks up whatever information is available, it might be less or more than we know at | ||
| the moment depending on what has been marked-up and linked. The <gi>listWit</gi> |
pages/workHeader.xml
Outdated
| picks up whatever information is available, it might be less or more than we know at | ||
| the moment depending on what has been marked-up and linked. The <gi>listWit</gi> | ||
| contains instead a statement about the manuscripts used for an edition, which can be | ||
| nested, and also might contain manuscripts which we do not have yet.</p> |
There was a problem hiding this comment.
My impression is that "and also might contain manuscripts which we do not have yet" is now in contradiction to the above described practice of creating stub records. Maybe it could be deleted.
pages/bibliographic-references.xml
Outdated
| <head>Bibliographic references for enriched records</head> | ||
| <p>Following <ref target="https://github.com/BetaMasaheft/Documentation/issues/2630">issue | ||
| 2630</ref>, in cases of enriching a historical catalogue description, such as verifying images or | ||
| adding new information, to acknowledge this, one can include the marked-up by a |
There was a problem hiding this comment.
Would "one can include a bibl element" work?
|
@eu-genia, I have a question: i see that technically merging is possible. Do I need to wait for your active approval, or is Dorothea´s review enough to merge the updates? |
There was a problem hiding this comment.
Thank you.
Please as already suggested - in the very first comment in this pull request add links to all the issues and discussions these changes attend to. Then the commit will be linked to the issues and one will be able to properly document what has been done.
Thank you.
| missing, and update them to point to the other identifier.</p> | ||
| </div> | ||
| <div type="level2"> | ||
| <head>Differenciating between various levels of description</head> |
| </revisionDesc></egXML> When the record has stopped being a stub as it has been | ||
| developed further then in the first change line the word stub must replaced with | ||
| something like "initial version" or anything else. After the description is | ||
| completed, the above example can be changed into something like the example below. |
There was a problem hiding this comment.
I would remove the sentence
"After the description is
completed, the above example can be changed into something like the example below."
It repeats what has been said and misleads, as this change is necessary not only when the description has been completed, but at any point when it is not a stub any more (the judgement on that is up to the cataloguer of course)
| <revisionDesc> | ||
| <change who="ES" when="2024-04-10">created stub</change> | ||
| </revisionDesc></egXML> When the record has stopped being a stub as it has been | ||
| developed further then in the first change line the word stub must replaced with |
| <change who="ES" when="2024-04-10">created stub</change> | ||
| </revisionDesc></egXML> When the record has stopped being a stub as it has been | ||
| developed further then in the first change line the word stub must replaced with | ||
| something like "initial version" or anything else. After the description is |
There was a problem hiding this comment.
"something like "initial version" or anything else" - does not sound good as a guideline. Guidelines should be clear and concise. I think "the word "stub" in the <gi>change</gi> element must be replaced" is sufficient.
| guidelines</change> | ||
| <change who="DR" when="2019-04-09">Added before creating a manuscript record | ||
| paragraph</change> | ||
| <change who="NV" when="2024-12-13">added a paragraph about "Differenciating between various |
| <egXML xmlns="http://www.tei-c.org/ns/Examples"> | ||
| <revisionDesc> | ||
| <change who="ES" when="2024-04-10">created an initial version</change> | ||
| <change who="NV" when="2024-12-13">completed the description, change the first |
There was a problem hiding this comment.
"change the first line above" - delete
| </egXML> | ||
| <p>The above example would point the bibliographical reference directly to the <gi>title</gi> with that ID.</p> | ||
| <egXML xmlns="http://www.tei-c.org/ns/Examples"> | ||
| <head>Bibliographic references for enriched records</head> |
There was a problem hiding this comment.
This paragraph should go AFTER the general paragraph on references
| <change who="DR" when="2019-06-17">added specification and example for title</change> | ||
| <change who="NV">added link to the bibliographic reference and few specifications for |
There was a problem hiding this comment.
because of the reformatting it is very difficult to trace what has been changed. better avoid indenting in long records created by others when just small changes are introduced. thank you
| >123</citedRange></bibl> | ||
| <bibl type="KRZ"><ptr target="bm:KRZ"/><citedRange unit="item" | ||
| >123</citedRange></bibl> | ||
| </listBibl> |
There was a problem hiding this comment.
while we are at it - please add also
<bibl type="PEMM">
<ptr type="story" target="bm:PEMM"/>
<citedRange unit="item">1022</citedRange>
</bibl>
to the list, thank you!
| manuscripts as <gi>witness</gi> as well. Since identification of witnesses is part of | ||
| the research, whoever has done it should be acknowledged in the <gi>note</gi> and | ||
| bibliographic references (if available).</p> | ||
| <p>If someone decides to list manuscripts that were neither used in the edition nor fall |
There was a problem hiding this comment.
I would strongly recommend restoring the paragraph as it has been
All manuscript records containing the work if they have been fully encoded with the correct reference are displayed in the app anyway. If manuscripts are known to contain the work but have not been properly encoded yet it is recommended to list them as <gi>witness</gi> (and make sure a corresponding stub or an external reference for the manuscript exist).
In general we should not describe practice that has not been used or discussed properly. The rule is simple: list witnesses that you consider important, if they are not yet properly encoded, create stubs.
It goes without saying that one can add notes everywhere on anything.
I think we have talked about this already. |
I have tried to update three pages of the guidelines, I hope I have not messed up and my changes are helpful! Thank you for your insights for improvements!