National Library of Spain comments on proposals and discussion papers:

Proposal No. 2022-07: Modernization of Field 856 Second Indicator and Subfield $3
We still don't see the cost-efficiency of this change, and we are concerned about the legacy massive modification overheads, but otherwise, we are not against its content and see the logic behind the proposal.

Proposal No. 2022-08: Recording Persistent Identifiers and File Formats in Field 856
We support this proposal. We really appreciate the addition of $h. We will need further information about when the cataloger would have to fill $g and/or $u, we do not understand why filling a $u if we already have a PID in $g. And still we have another question, could we fill $u with a PID?

Discussion Paper No. 2022-DP06: Defining a New Field to Record Electronic Archive Location and Access
6.1. The proposed new field 857 indicators mirror some of the indicators in 856 (Electronic Location and Access). Have we covered all the relevant access modes, or are there other access methods that should have their own indicators?
Maybe it should be considered all the indicators in 856, just in case.
6.2. The proposed new field 857 includes many of the same subfields in 856 (Electronic Location and Access); should all the subfields copied from 856 be kept?
6.3. In this new discussion paper, an additional subfield for the name of the archive has been provided in $c and the archive agency in $d. Is it clear how to use these subfields and are both needed?
Yes, we think so
6.4. Does this paper accommodate the range of digital preservation systems or tools that might exist and need to be recorded in field 857?
Yes, at least by now
We have a remark about $f as we think it covers different things (completeness and times a resourced has been saved) that doesn't have to be related: the number of times a resource has been saved doesn't imply its completeness. Maybe it would be better to use a different subfield for each one.

Discussion Paper No. 2022-DP07: Adding Subfield $3 to Field 041
6.1. Has the need for defining subfield $3 for the 041 field been sufficiently demonstrated?
6.2. Has the repeatability of field 041 in circumstances other than the accommodation of non-MARC language codes been sufficiently justified?
Are there circumstances other than the use of more than one type of language code in a description, or the presence of multiple works with different language information, where the ability to repeat the 041 field might be beneficial?
No comment
6.3. Would the presence of multiple 041 fields in a bibliographic record create additional ambiguity or confusion? If so, how might the situation(s) be rectified?
We think it is clear enough using $3
6.4. Are there other potential issues that need to be taken into account?
No. We missed examples of other kind of resources.

Discussion Paper No. 2022-DP08: Adding Subfields $0 and $1 to Fields 720 and 653
6.1. Do you agree that it should be possible to associate an uncontrolled name or subject with a linked data entity?
6.2. Does adding $1 to 720 and 653 provide a satisfactory way to make that association? If not, are there alternative approaches that should be considered?
6.3. Should $0 also be defined for non-URI identifiers? If so, will it be necessary to amend the definition of $0 in Appendix A?
We don't understand this question related to $0, as $0 was already applied URI or text-alike:
$0 - Authority record control number or standard number
Subfield $0 contains the system control number of the related authority or classification record, or a standard identifier. These identifiers may be in the form of text or a Uniform Resource Identifier (URI). If the identifier is text, the control number or identifier is preceded by the appropriate MARC Organization code...
6.4. Are there relevant differences between names and subjects that should lead us to define $0 and $1 for one but not the other?
6.5. Are there any potential consequences that this paper does not address?
No comment

Discussion Paper No. 2022-DP09: Defining a Field for Standardized Provenance Information
National Library of Spain welcomes greatly this paper about provenance and material evidence recording. We have been working on recording these data into MARC21 environment and make them available and searchable to its users, and has found the same problems the German colleagues has. We hope this trigger a more in depth discussion about the holdings format, particularly about recoding relationships between items and agents. In our implementation, we have always sought to record these relationships in item records, as we think this is the right place to do according to the reference models, often overstretching the use of MARC capabilities through local refinements, so we deeply appreciate this effort toward interoperability and standardization.
Accordingly, we generally do not support recording these data in the bibliographic resource, with the possible exception of manuscripts and other singleton resources, but we agree that MARC21 should not prevent it, allowing the recording of these relationships in either Bibliographic or Holdings format. For this reason, anyway, we don't support Option 1 nor Option 2.
Option 3 and 4 have been considered, although we couldn't reach a consensus. $0 seems the fastest way to achieve a relationship between an agent and an item, although it seems to go against the structure of a free note. Field 361 is a more granular approach, but the field structure is awkward, sometimes resembling an access point, with the Names group, but mixing data from provenance marks, accession dates, location...
We think that any of both approaches are more suitable if recorded in Holdings records. Otherwise, it can be a long and confusing bibliographic record, especially in big heritage libraries, which may have many copies from the same manifestation, each with a long ownership history.

6.1. Is the need for accommodating authority record control numbers for prior personal/corporate/jurisdictional owners/collections together with controlled terms for material evidence related to the respective prior owners sufficiently demonstrated?
6.2. Which one of the four options is preferred, as described in section 3: 1) no changes, 2) 561/7XX with $8, 3) additions to field 561,or 4) a new field "361"?
Options 3 and 4
6.3. If option 4 is preferred: Which one of the available field numbers should be chosen, "361", or a different one?
361 is fine
6.4. Is the proposed field name appropriate?
6.5. Does the internal structure of the new field, especially the subfields, meet the requirements?
We think that the "name group" does not need so many subfields, as it's not in fact an access point.
Do the subfields fit into the MARC structure?
$e relator term (and $4) should be left only for real access points.
6.6. More specifically: Can the issue of multiple links from one MARC field to separate authority records be solved? Is the distinction between subfield $0 and subfield $w, by changing the scope and internal structure of $w, a path worth exploring?
An alternate worth exploring to solve this issue is separating the ownership and the provenance mark data in different fields, using, for example, 561 $0 for recording the former owner and the 361 to record material evidence (with a $0 to an ID for the mark, if applicable).
6.7. Is there a solution for the non-repeatable subfield $2? Can the recently designed subfield $7 play a role here?
This conundrum can also be resolved with the proposal above
6.8. Is there anything else that should be taken into account?
Maybe devising a proper access point in the Holdings format could be the shortest way to implement Agent-Item relationships from LRM/RDA.

Discussion Paper No. 2022-DP10: Defining a New Subfield in Field 264 to Record an Unparsed Statement
We do not agree the Discussion Paper
Discussion Paper No. 2022-DP11: Defining a New Subfield in Field 490 to Record an Unparsed Statement
We do not agree the Discussion Paper

Lourdes Alonso Viana
Servicio de Coordinación y Normalización
Departamento de Proceso Técnico
Biblioteca Nacional de España
Este mensaje y cualquier fichero adjunto están dirigidos únicamente a sus destinatarios y contiene información confidencial. Si usted ha recibido este correo electrónico por error, le informamos que no puede realizar ninguna revisión, alteración, impresión, copia, transmisión, difusión ni utilización alguna de este mensaje ni de cualquier fichero adjunto que pudiese contener. La realización de cualquiera de los actos indicados está expresamente prohibida por las Normas que regulan estas materias. Por todo ello se solicita que, en caso de existir error en la recepción de este mensaje, se lo notifique al remitente respondiendo a este e-mail y elimine el mensaje y su contenido inmediatamente. La Biblioteca Nacional de España se reserva las acciones legales que le correspondan en el caso de que se infrinja lo indicado anteriormente.
The information in this e-mail and any attachments is confidential and it is intended for the addressee only. If you have received this e-mail in error, you are notified that any revision, amendment, print, copy, disclosure, distribution or use of the contents is unauthorized. Carrying out any of the above actions, is expressly banned by rules governing this matter. Hence we request that if you are not the intended recipient, please notify the sender answering this e-mail, and delete the message and any attachments. The National Library of Spain reserves itself the right to take the appropriate legal actions in the event of the above mentioned matter is being infringed.