Reworking how unknown information is handled

[paulmillar]

What is the problem that your suggestion solves?

Information may be unavailable for any number of reasons.

Appendix 3 provides a mechanism that aims to address this problem specifically when information is mandatory. It does this by providing a list of place-holder values that should be used under different circumstances.

There are a number of potential problems with this approach:

1. The place-holder values are all strings. Therefore, the values cannot be directly applied to fields of other type (e.g., numbers, dates, etc).
2. By defining place-holder values, it becomes valid to include any of these place-holder values in any text field. For example, controlled vocabularies would need to be extended to include these place-holder values. In general, this makes validation much harder, as any value could be missing. (This is broadly analogous to the null-reference problem, which Tony Hoare described as his "billion-dollar mistake".)
3. Many (most?) of the standard values are poorly described. The precise semantics and circumstances where they should be used are open to interpretation. (e.g., what are the processing expectations when a client receives such a value?)
4. Many of the terms are arguably a crutch to more fundamental problems with the metadata schema. For example, publishing a record with <title>:unap</title> calls into question why title is a mandatory metadata property: either title is mandatory (and the record shouldn't be accepted, or perhaps the definition of title needs adjusting) or a title "makes no sense" so title shouldn't be mandatory.
5. It is unclear what should happen if a non-mandatory metadata property has a value from Appendix 3 standard values. Is this "legitimate"? Would it have any special meaning? Would it have the same semantics as simply omitting the property? If both are valid, which approach is preferred?
6. On a related note, Appendix 3 states the values are for mandatory properties. However, information may be temporarily unavailable for non-mandatory properties. This scenario is not covered.
7. The text processing is not clear. For example, <title>:unkn</title> would indicate that the title is "known to be unknown", but would <title> :unkn</title> (space before the :) or <title> :unkn </title> (space after the n) or <title> :unknown</title> (extra characters after the n) also carry the same meaning. Is there a way to represent a property value with one of these standard values? More generally, are metadata property values that start with a : now reserved?

What solution might meet your needs?

An alternative approach might be to use XML attributes to carry this information.

For example:

<resourceType status="unallowed"/>

The values of this status attribute would be a controlled vocabulary, similar to Appendix 3.

This status attribute could be applied to any XML element, allowing its inclusion for metadata property of any type (string, integer, date, ...) without being confused as a valid value and without having to extend validation rules.

For metadata properties with multiple cardinality (e.g,. Creator), the status attribute could be applied to the collection element, indicating that this information is currently not available.

<creators status="inaccessible"/>

It could also apply to individual items within the collection; e.g.,

<creators>
    <creator status="unallowed"/>
    <creator>
        <creatorName xml:lang="en" nameType="Organizational">California Digital Library</creatorName>
        <nameIdentifier schemeURI="https://ror.org/" nameIdentifierScheme="ROR">https://ror.org/03yrm5c26</nameIdentifier>
    </creator>
</creators>

Another alternative would be for DataCite to drop support for place-holder values.

Are they really used in practice? If so, doesn't this suggest that certain mandatory metadata property would be better as a recommended property? The publisher could simply omit the information and update the record when (and if) information becomes available. If metadata properties should stay mandatory then a publisher would need to delay obtaining a DOI until after all the mandatory metadata property values are available.

Your name

Paul Millar

Your organization

DESY

What alternatives have you tried or considered?

No response

Is there anything else you would like to share?

No response

What group(s) would benefit from your suggestion?

• DataCite members registering DOIs and metadata and administering accounts
• Developers building integrations with DataCite services
• Harvesters who index DataCite DOIs and metadata
• Individuals or institutions analyzing DataCite DOIs and metadata
• DataCite staff
• Other

If other group(s), please describe.

No response