Comments COAR-Repositories

First, thank you for putting these recommendations together. Overall, I find them to be extremely helpful.
I think the presentation of the recommendations on this page would benefit from a different arrangement to make it easier to find information on the relevant recommendations. Since almost all of the bulleted recommendations have overlap between the 3 categories of people (1. repository managers, 2. repository software/platform developers, and 3. content creators), I recommend consolidating the recommendations to remove overlap, explaining them in prose (as you have done here), and then adding a table to indicate how each recommendation is relevant to the 3 categories of people. For example, the condensed recommendations would be the rows, and the columns would represent the 3 categories of people. Individual cells would have e.g., check marks to indicate who needs to be concerned with each specific recommendation. Then I recommend reorganizing the rest of the document so that it is organized around the actual recommendations and not the categories of people. In the current organization, for many of the sections, I had a hard time figuring out exactly which of the recommendations was the focus of the different sections, and I kept having to go back to the recommendations to try to figure it out.

We declare the original language of the resource at the item level. All the metadata is described in English as an international language, following the agreement of the European Commission. But we have two users interfaces, one in Spanish (our language) and one in English in order to increase international visibility (this interface nowadays is updating).

The xml:lang attribute is specific to XML. I suggest making this recommendation agnostic to the metadata representation, or give xml:lang as an example (“e.g.,”) here.

We always respect the language of the resource. If, for example, the resource is in Spanish, in the case of keywords, we use qualifiers to differentiate the metadata in different languages:

dc.subject.keywordseng

institutional repository

dc.subject.keywordseng

interoperability

dc.subject.keywordsspa

metadatos

dc.subject.keywordsspa

repositorio institucional

dc.subject.keywordsspa

interoperabilidad

https://ru.micisan.unam.mx/handle/123456789/22232?show=full

In linguistics and language studies, ISO-639-3 (3-letter) codes are a standard. First, most languages don’t have 2-letter codes, and when they do they are often confusing because they don’t represent languages (e.g. cr for ‘Cree’,  ms for ‘Malay’, or zh for ‘Chinese). This obscures exactly the type of diversity we hope to promote. Linguists and language archives are also increasingly using glottocodes (https://content.iospress.com/articles/semantic-web/sw212843) for “languoids”, since what gets to “count” as a language is largely political. Consider having an optional field to include those as well. 

In relation to this topic, if a document has a complete translation, should 1 item be generated for each version and proceed to connect the versions with relation metadata? Or what would be the recommendation for those cases?

Curious about singling out ORCID as that’s mostly used for living people/researchers. I get the feeling these recommendations are more about scientific/data repositories and not for other digital collections that contain more archival or historical data. This is already an accepted convention to record identifiers for name authorities when they exist. — maybe just making clear the audience for these recommendations in the introduction would help?

This seems aspirational but vague.  How would we go about integrating Wikidata in DSpace?

 
Besides the recognition of the translator we encourage to recognize all the professionals involved in the editorial process(I added) mentioned in the resource, it takes a lot of time but it is worthy. This is an example:

.contributor.assistanttotheeditorinchief

Cruz Salas, Minerva

dc.contributor.businessmanager

Zempoalteca Quintana, Mario

dc.contributor.copyeditorandtranslator

Dashner Monk, Heather

dc.contributor.designer

Pérez Ramírez, Patricia

dc.contributor.editorinchief

Jiménez, Teresa Andreu

dc.contributor.layout

Álvarez Sotelo, María Elena

dc.contributor.salesandcirculationmanager

Creamer Tejeda, Cynthia

dc.contributor.translator

Fernández Hall, María Cristina

In fact, RECOLECTA evaluation for repositories considers this point: “4.5.- Existe un campo específico para indicar la descripción de la colaboración.  En este campo se registra la entidad o persona responsable de coordinar, corregir, comentar o, en general, contribuir de alguna otra manera al desarrollo del recurso” (4.5.- There is a specific field to indicate the description of the collaboration. This field records the entity or person responsible for coordinating, correcting, commenting or, in general, contributing in some other way to the development of the resource.
https://calidadrevistas.fecyt.es/sites/default/files/informes/2021guiaevaluacionrecolecta_vf.pdf
 

Could potentially be problematic in implementation if the automatically assigned codes did not accurately describe the content uploaded to the repository.  Users are more likely to accurately classify their work than library staff or an AI.

Agree with ISO recommendation to increase support for using ISO-639-3 codes, but this then appears to be at odds with the first set of recommendations for repository managers. Is the recommendation existing because of lack of support (screen readers, IIIF not supporting 3-letter codes) and ISO 3 letter codes actually desired over ISO 2 letter codes? It would be helpful for this to be stated more clearly. Appendix 4 also unclear on this. Maybe some sort of decision tree format in the recommendation text?

Seems difficult to implement as content creators are unlikely to complete this step unless we make it compulsory.  Since submission of pre-/post-prints and OA articles to our repository is voluntary, attempting to implement such a policy would likely deter submissions.  In the case of graduate students, who are already required to submit their theses, this step would necessitate significant manual review.  We could, however, provide a section in our submission guidelines and help text on how to add this information to encourage our submitters.