Harmonise or refine definition of DOIs

[nautolycus]

Pull request #571 proposes a new item _audit_conform.dict_DOI which I hope is not controversial in itself - it simply extends the list of endpoints for locating a dictionary to which the data file conforms, and seems essential if DOIs are to become the preferred way to locate dictionary resources.

I have copied the block of text describing a DOI from other definitions (e.g. save_citation.doi). These interpret the DOI as an identifier string, and for example give
_description_example.case 10.5517/CC6V9DQ

However, the definition for save_audit_support.funding_organization_doi expressly states

In accordance with CrossRef guidelines, the full URI of
the resolved page describing the funding organization
should be given (i.e. including the https://doi.org/
component).

As mentioned in Issue #275 this appears to be effectively a CrossRef mandate. I think this is unfortunate - a permanent identifier should be recorded independently of a particular resolving infrastructure, and perhaps the dataname should have been named something else, e.g. _audit_support.funding_organization_pURL (for persistent URL to distinguish it from _audit_support.funding_organization_URL).

Anyway, should we

• Leave the other definitions as they stand?
• Change the examples (and explanatory text) in the other definitions to enforce https://doi.org/ prefixes?
• Change the definitions to say that either form is acceptable?

I notice incidentally that the _dictionary.doi string in the current 3.2.0 release version on the IUCr web site says

    _dictionary.doi
        https://doi.org/10.1107/cifdic_000002

[jamesrhester]

I agree that we should stick with pure DOIs rather than express them as URLs.

[vaitkus]

I would also prefer to have DOIs without the resolver part. I have a few additional questions related to this:

1. If both a DOI and an absolute dictionary URL (_audit_conform.dict_location) are provided, but with differing values, which one takes precedence? Of course, the handling of such incompatibilities could be left to the resolving software, however, it might be better to explicitly specify the preference.
2. Is there a need to add a corresponding definition of a dictionary DOI to the IMPORT category of the DDLm reference dictionary? This would allow using the dictionary DOI as an identifier in import statements (although a similar result could be achieved by specifying the dictionary location through the DOI resolver).

Interestingly enough, the _dictionary.doi in the current 3.2.0 release is present in the version on the IUCr website, but not the DDLm repository tag (they differ slightly, see issue #575). Since the _dictionary.doi attribute definition contains an explicit example of a bare DOI, I would treat the full URL DOI as a small oversight introduce during the sequential editing of the dictionary.

[nautolycus]

1. My current draft of the ITG chapter on managing dictionaries reads:

For robustness, since 2023, digital object identifiers (DOIs) have
also been introduced for dictionaries. A DOI is a persistent
identifier that can be resolved to an Internet location using a
resolver service, thus allowing for changes in the end-point URL to be
handled transparently within the resolver service. Registered DOIs are
also included in the dictionary register and, where available, should
be considered the primary means to locate the associated
dictionary. The standard resolver for DOIs is provided by the CrossRef
organization; to link to a DOI such as 10.1107/cifdics_000001, one
may prefix the address of the resolver service:
https://doi.org/10.1107/cifdic_000001.

When I update the core dictionary chapter I shall make a similar point about preferring the DOI if present.

2. I don't have a preference here, given that one can state the CrossRef resolver DOI.

[vaitkus]

My current draft of the ITG chapter on managing dictionaries reads:
...

@nautolycus Ok, it is useful to know that DOI should be preferred. It would be nice to have stated in the reference dictionary itself given that users might not have access to the ITG (if this does not go against the editorial practices).

I don't have a preference here, given that one can state the CrossRef resolver DOI.

Ok, then we should probably adopt a simpler solution that does not require the addition of new data items. Even the dictionary name plus the version number should already serve as a unique identifier after all.