Controlled list of values for relationType

[RKrahl]

We still do not have finalized the controlled lists of values for several properties. I hereby open individual issues for each of them.

The relationType is intended to describe the nature of the relation with some other entity for RelatedIdentifier. At the moment we have:

• IsDescribedBy (intended to be used for articles describing the instrument or other documentation)
• IsNewVersionOf / IsPreviousVersionOf (intended to be used for instruments in the case that a new PIDINST has been attributed to the instrument after some major modification, to relate the old with the new version and so to be able to track the history)
• HasComponent / IsComponentOf (intended to be used for larger instruments that are composed of parts, such as multiple sensors that are considered to be instruments on their own. If one wants to issue PIDINSTs for both, the composite instrument and its individual components respectively, these PIDINSTs would relate to each other using these types)
• References (kind of a fetch all "other" type, if the related entity provides information about the instrument)
• HasMetadata (intended to be used to link to other metadata for the instrument, maybe using some richer, community specific schema then ours)

What is missing here? Are there other relations not yet covered? In #17 @ngalbraith suggested to link to deployments of an instrument. Should we add something similar to WasUsedIn or what would be the proper relation type for that?

[huberrob]

Sometimes instruments are or become permanently attached to each other so maybe we also need something like: 'IsPartOf' Or 'IsAttachedTo' ?

[ErinKenna]

I'd like to be able to distinguish between references that are different protocols for sampling, calibration, installation, maintenance, etc. A similar approach to the additional name (free-text) property relating to AlternateIdentifier discussed here https://github.com/rdawg-pidinst/schema/issues/24#issuecomment-475156528. For me this would probably provide enough context for users not to have to click through each URL or DOI to find the relevant resource.

[RKrahl]

@ErinKenna sorry, I don't quite understand what the issue is here or what you suggest. Could you elaborate?

[RKrahl]

HZB would in fact have a use case for IsAttachedTo: at the BESSY II synchrotron radiation source we distinguish beamlines and experimental stations. The beamline generates a beam of photons, conditions it and guide it through to the experimental station where the measurement takes place. Some of the experimental station are flexible and can be moved between beamlines (and that is why we need to distinguish them in the first place), other stations are permanently attached to their respective beamline. For the sake of consistency, we plan to attribute separate PIDs to all beamlines and experimental stations respectively. For the fixed stations and their respective beamlines, we link the pair of PID records using RelatedIdentifier, see the UE52_PGM Ion trap beamline and Ion Trap station for an example.

We couldn't make use of IsAttachedTo though, because we use DataCite DOIs and are thus restraint to the DataCite version of the schema. So we use relationType=References instead. But I thought I provide this example to illustrate a potential use of IsAttachedTo nevertheless. I don't know how common similar cases are and whether it warrants the addition of this relation type. (More examples welcome.)

I don't think IsPartOf would be an appropriate name for this case. Firstly, because it rather hints for a parent / child sort of relation which doesn't really match the situation here. Secondly, it might cause confusion because the difference between IsComponentOf and IsPartOf would not be clear.

[RKrahl]

In the preparation of submitting the schema as a RDA recommendation, we plan to get a decision on all pending open questions during the next monthly meeting on 4th August.

For the controlled list of values, I suggest to leave it with those that have already been used in the prototype implementation or that have a clear rationale for a use case. It will be much easier to add another missing value in a future version of the schema than to remove one that turn out to be less useful.

For relationType we have so far:

• IsDescribedBy, IsNewVersionOf, IsPreviousVersionOf, HasComponent, IsComponentOf, References, and HasMetadata from the original draft of the schema,
• WasUsedIn as suggested in #17,
• IsIdenticalTo as suggested in #37,
• IsAttachedTo as suggested by @huberrob above.

I suggest to leave it with this list for version 1.0.

[ErinKenna]

@ErinKenna sorry, I don't quite understand what the issue is here or what you suggest. Could you elaborate?

I'll try an explain this better with an example.

I have an instrument with multiple related resources;

• deployment manual
• calibration manual
• decommissioning manual
• maintenance checklist

I would reference them like this;

<relatedIdentifiers>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy">https://doi.org/10.1071/example1</relatedIdentifier>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy">https://doi.org/10.1071/example2</relatedIdentifier>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy">https://doi.org/10.1071/example3</relatedIdentifier>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy">https://doi.org/10.1071/example4</relatedIdentifier>
</relatedIdentifiers>

What I was proposing for discussion was an additional "name" property (like that discussed for the AlternateIdentifier discussed here #24 (comment)).

Something like;

<relatedIdentifiers>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy" relatedIdentifierName="Deployment manual">https://doi.org/10.1071/example1</relatedIdentifier>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy" relatedIdentifierName="Calibration manual">https://doi.org/10.1071/example2</relatedIdentifier>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy" relatedIdentifierName="Decommissioning manual">https://doi.org/10.1071/example3</relatedIdentifier>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsDescribedBy" relatedIdentifierName="Maintenance checklist">https://doi.org/10.1071/example4</relatedIdentifier>
</relatedIdentifiers>

This allows me to provide enough context for applications and users without having to resolve each related resource to discover what it is.

[RKrahl]

@ErinKenna, many thanks for the clarification. Now I understand your proposal. In principal, I don't see an issue with that.

But now, I have another problem: we had version 1.0 of the schema on the agenda of the monthly group meeting two days ago. It was partly a not so easy discussion and I'm rather happy that we nevertheless managed to get a final decision on all open issues, at least with respect to version 1.0, and that we now have a clear roadmap towards the submission to RDA. So, I'm a little reluctant to reopen that parcel again, even for a relative minor change as your proposal. I'd like to confer with the other group chairs on how we proceed first.

[RKrahl]

@ErinKenna, another remark: your proposal is in fact a new subproperty relatedIdentifierName of RelatedIdentifier. Strictly speaking, this is unrelated to the controlled list of values for relationType. I'd suggest that you open a new issue for that so that we keep a record for it and have a place for the discussion that is not hidden in the thread of an already closed issue.

[markusstocker]

Sounds sensible to me and since it is minor I suggest to let this flow into 1.0 and make the cut here so that we can proceed with submitting 1.0.

[ErinKenna]

Thanks @RKrahl and @markusstocker. I've created a new issue.
Add relatedIdentifierName subproperty to relatedIdentifier #54
I don't want to impede the 1.0 version release at all and I have no problem with this new issue remaining open for discussion in the next version.