Update relation types to align with DataCite

[rebeccaringuette]

The relation types currently indicated in Table 5 of the published guide needs some updating or at minimum a mapping to the correct relation types available in DataCite. Below is a draft of my best guesses (identical mappings ignored). Interested in potentially better choices, especially for the last one.

Current relation type | DataCite relation type
HasComponent | HasPart
IsComponentOf | IsPartOf
WasUsedIn | IsRequiredBy (???) or IsSupplementTo ??
IsAttachedTo | (deprecate?)

[RKrahl]

I beg to differ.

PIDINST is a metadata schema for the description of an instrument instance. It defines the properties that the PIDINST working group suggests to be registered along with the PID through a relevant PID infrastructure in order to identify the instrument.

The PIDINST schema is formulated agnostic of the concrete implementation in any given PID infrastructure and does not endorse to use a particular one.

Indeed, the PIDINST working group did evaluate some concrete implementations, including using DataCite DOIs for instrument PIDs and found them to be usable in principle. But of course, if one wants to use DataCite DOIs, one cannot use the PIDINST schema as is, but needs to map it onto the DataCite schema. This mapping is not perfect, there is some loss of information on the way and that is one of the drawbacks of using DataCite DOIs. The mapping is btw. described in a separate document and the shortcomings of the DataCite schema are documented there.

There are other implementations of instrument PIDs that allow to use the PIDINST schema natively and that do not have that disadvantage. And therefore, PIDINST should not limit its schema to what can be expressed in DataCite.

Indeed, there are no appropriate relation types for WasUsedIn and IsAttachedTo in DataCite. But these relations have relevant use cases for the description of instruments and therefore need to be retained in PIDINST. This can only be fixed at the DataCite end, by adding appropriate values there.

[rebeccaringuette]

Granted. But we can decrease the loss of information by enriching the mapping to DataCite, and we can increase the discoverability of that information by mapping to more relevant places (e.g., the keyword-like terms mentioned in other issues). Updating the proposed relation type mapping. The main difference is using "IsCitedBy" as a default relation type to ensure the connection between items is preserved. If this were schema.org, I would choose 'mentions', but ?

Current relation type | DataCite relation type
HasComponent | HasPart
IsComponentOf | IsPartOf
WasUsedIn | IsSupplementTo
IsAttachedTo | IsCitedBy

Reading the notes and issues section of the schema-datacite.rst file... We have similar problems in Heliophysics with mapping datasets to DataCite and we are discussing our mapping for instruments right now. Below is a list of conventions we chose or are considering for instruments:

• We map measuredVariable metadata into Subject for the maximum flexibility of detail and because it is typically a keyword-type field.
• At least in DataCite v4.6 and on, a title value without a titleType implies "name". I see no problem there.
• For items that are only metadata (and not files) such as Instruments, the publisher would be the entity serving and maintaining the metadata. The publicationYear would be the year the DOI is created. (We do the same thing for publicationYear with our data when a DOI is created, even if the data has been available for a while.)
• (skipping the relation type item since that is above)
• a simple solution to the serial number problem could be to lean on the freedom allowed in the field. Since free text is allowed, the serial number could be indicated with "serial number: ABC1234" and similarly for model number ("model number: value").
• About the model name issue, I wonder.... Since a model name 'identifies a series of instruments...', what if a separate instrument record were created for the model with a PIDINST type of "Instrument Model" (or similar)? All the model information would be entered there (e.g., model number -> alternate identifier, model name -> title, etc). Then, the specific instance of the instrument with a matching model number would reference the model through the relatedIdentifier field, ideally to the PID for the instrument model. The relation type could be "IsVersionOf" in datacite for the link from the instrument to the model instrument. This would be extremely useful for large networks of instruments (e.g., magnetometer networks with hundreds to thousands of them) of the same model number / similar. I initially like this because the creation of the instrument records for each instance would be greatly simplified and easier to maintain, plus it would be linked through identifiers to help funders more accurately determine what instrument models the data depends on (e.g., this model is ancient but used all over -> high impact choice for funding). Very interested in thoughts on this since we (Heliophysics) have to decide how to do this soon.