All feedback is welcome, but any affirmations, enhancements, or correctives to the draft regarding DP11 would be especially appreciated.
Again, if I could have your feedback by 5 pm, tomorrow, June 18.
Proposals
2024-05 (Add subfields $0/$1 to fields 506 and 540):
Support the inclusion of $0/$1 for fields 506 and 540, per the paper.
Discussion Papers
2024-DP06 (Add subfields $0/$1 to Field 024) replies:
Support this paper.
6.1 Yes.
6.2 Yes.
6.3 Yes.
6.4 As $a is Not Repeatable, then $0/$1 should be Not Repeatable – there should be a "lock" between $a$2$0/$1
2024-DP07 (Add subfield $3 to fields 508 and 511) replies:
Enthusiastically support this paper.
6.1 Yes.
6.2 Yes.
6.3 No.
2024-DP08 (Add subfield $7 to various fields) replies:
Support this paper.
6.1 Yes (was surprised these weren't swept into 2022-05)
6.2 Yes, this ground is well tilled in 2022-05
6.3 Yes, a holistic approach would be desirable, as a distinct paper.
6.4 No.
2024-DP09 (Add subfields $i and $4 to fields 368, 376, and 381) replies:
6.1 Generally, yes, as this would make the field contents more intelligible and perhaps actionable. A slight concern about catalogers getting lost in rabbit holes/indecision of deciding which term/code to enter.
6.2 No.
6.3 Wouldn't object to a fast-track if discussion points in that direction, but also wouldn't object to let this "ripen"
2024-DP10 (Redefine subfield $b in Personal Name X00 fields) replies:
6.1 In principle, yes. One might be concerned that "regnal" number perpetuates the Western bias that enlarging beyond Roman numerals is trying to achieve, although the effort to differentiate from intra-familial numberings is appreciated.
6.2 It might be preferable to further explore the term "regnal" and possible alternatives.
6.3 No, beyond the aforementioned concern with "regnal"
2024-DP10 (Tagging Transliteration Schemes and BCP 47 in $7+ subfields) replies:
A general comment: the complexities of the dynamic addressed and the solutions put forward, highlight the overall challenges of implementing 2022-05, not that it will be reversible.
Unlike most discussion papers, this paper fails to ask if the use case has been made at all.
6.1 Neither option is preferred. A more robust, flexible, and source-agnostic solution would be desirable.
6.2 No. See 6.1
6.3 See 6.1. This question should be addressed in the context of a better solution to the use case.
6.4 There very well may be, but the challenges of solving the given use case need to be explored and resolved further before other considerations are taken up. Alternatively, given the current complexities, the authors should be responsible for considering further use cases.
6.5 The glaring challenge is the incorporation of subfield delimiter notation within a given subfield. This is all tolerably clear when the real subfield delimiter and label are bolded, but that is not how MARC operates. I worked with an early ILS where the insertion of a subfield as a "$"+letter combination and the use of "$" as a text character were frequently confused. And then there is the challenge of the non-actionable text "Applies to subfield [letter]" The actual codes are practically unintelligible for human eye-reading; the text elements are unintelligible to the machines who can make use of the codes. What is the value of any of it?
6.6 None of the syntax makes sense. The question should be, "Can it be expected that the proposed syntax would make sense for machine actionability?"