@TAC_NISO I read the document and I appreciate very much an attempt to harmonize with EOCS. Also, I need to say that I should support @erik-desci in his reply to paragraph 3.6.1:
I see where section 3.6.1 emphasizes the importance of “centralized” persistent identifier systems. Recent concerns have been raised about the scalability of centralized systems in the naturally distributed landscape of academia. Any particular reason for the emphasis on centralization given recent issues?
The remark I want to place is based on paragraph 3.1.2.2 which says:
Importantly, the scalability of PIDs ensures that, as data volumes increase,
the benefits persist without a corresponding rise in overhead costs.
Here scalability should be indicated as the key point together with the resolver-side and client-side reproducibility of the PID itself, I think. In the context of the prevalence of rotting links, the overhead costs of the systems utilizing non-reproducible PIDs are becoming unpredictable as much as the amount of minted PIDs grows. My opinion here is that interoperability and reproducibility of the PIDs itself should become a part of the whole FAIR concept for PIDs, at least in the open science context. This opinion is based on the outcomes of the ExPaNDS project where we were working on openly shared intermediate datasets from the Photon and Neutron community, where rotting links became a problem even for principal investigators.
The next remark I want to place here is about paragraph 3.4:
Therefore, it is important that individuals and organizations actively contribute to and support the core PID infrastructures that underpin this ecosystem.
In the context of this paragraph, I am for a clearer distinction between the roles of the individual User and the Adopter in Table 2, cause the User may easily become an Adopter by nature in the context of federated or decentralised PID infrastructure implementation, but the definition of Adopter role is written keeping in mind that he is likely acting as a society, group or organization.
In the section 3.5 it is written:
Inadequate metadata support: Lacking the capacity to store comprehensive
metadata, impeding efforts to provide context and information about the
associated data. PIDs come equipped to integrate with metadata standards from
multiple institutions, allowing for the inclusion of crucial details that enhance
the understanding and utility of the research data.
I think, there must be a recommendation to implement the possibility of standardisation and one-click adoption of the predefined metadata schemas (via DTD, Common Grammar, JSON Field Table, etc.), because it is essential here not to link the given general purpose PID implementation hardly to the single schema.
In section 3.6 I am completely for the replacement of the term “Centralized” with the term “Registry-based” because the current term gives the connotation of the simplest complete database-like centralisation whilst even the DOI and Handle systems are implemented over the federated approach, and the internal metadata persistence handling is not built over the simple replication.
In conclusion. I want to repeat my sentence about interoperability and reproducibility of the PID itself, in the context of section 3.8. The interoperability (at least, temporarily dropping the question about reproducibility) of the given PIDs, APIs and usage methodologies should be included there, because it would become a quantitative criterion of success. As an example of this, the presence and coverage of a trustless API could be proposed.
). I’ve intentionally made the specification agnostic as to what prefix is used with a DSI.