Add entry field for Associated Datasets

[fostermh]

related to cioos-siooc/metadata-xml#89

Need a way to associate one dataset with another. This is not the same as linking to resources as it is treated differently in the xml and ckan.

[n-a-t-e]

What kind of inputs are you picturing in the metadata form?

[n-a-t-e]

Looking at our our slack messages from 2 months ago- we mentioned the option of listing all the published records from the metadata form. That would be nice for the user.

[fostermh]

I was thinking something like the following.

Example live ckan dataset: https://catalogue.hakai.org/dataset/1769a04e-b77b-409b-8e48-bc2098bbad3e

Example output on a dataset page in ckan:

Example on a dataset edit page:

[fostermh]

yes, I was thinking listing published records would be nice. Not sure about allowing full URLs. maybe just start with published records and go from there?

[fostermh]

Also, there should be a note to users indicating that links should be created from 'child' to 'parent'. so only one link is needed. no need to create the link in both directions.

[n-a-t-e]

ok if its just linking from child to parent then the UI would be just selecting the parent record, and there can only be one parent. So its just a single drop down. Sound good?
The list could be long so it would need some kind of type to filter functionality

[fostermh]

there could also be cross-references which could involve more than one record. The interface should allow for more than one entry.
Also, the interface will need to capture the association and initiative type. I think initiative type may be optional, however.

https://wiki.esipfed.org/MD_AssociatedResource

https://catalogue.hakai.org/dataset/cf7a6149-b34a-404c-88e1-c556bf361408

[n-a-t-e]

Also, there should be a note to users indicating that links should be created from 'child' to 'parent'. so only one link is needed. no need to create the link in both directions.

Oh I misunderstood this - you mean you do want to support linking in either direction (but not both).

I wonder if we can simplify this and just support linking to one parent and/or multiple related records (removing the child option to avoid the double linking issue). Users would create the parent and then when creating the child records they only have the option to select the parent record. Then we would have a dropdown with text "Select an associated record", and a relation type with options "parent dataset" and "related dataset"

[fostermh]

I think that would work as long as there is the option to have more than one "related dataset"

For example:

if A is a parent then:

• B links to A and C links to A.

if A,B, and C are 'related' then the relationship could be:

• A links to B, A links to C, and C links to B.

The system will still work if users do the revers links but they just don't need to.

[n-a-t-e]

I don't follow what you mean by all those links, but yes it would support linking to one parent and/or multiple related records.

Also it wouldn't modify the associated record, just the one the user is currently editing. There would be no indication in the associated record (in this tool) that something has been linked to it

[fostermh]

perfect. :-)

[Br-Johnson]

The ISO implementation of AssociatedResource is similar to DataCite's relatedIdentifier field. Can we use the DataCite schema in the Hakai metadata profile instead? This might simplify dataset granularity and versioning recommendations.

https://support.datacite.org/docs/datacite-metadata-schema-v44-recommended-and-optional-properties#12-relatedidentifier

[fostermh]

how do you envision this being implemented?

[Br-Johnson]

I would envision a 'Related Identifiers' section in the metadata intake form in the Data Identification section that comes right after the DOI section.

• A free text box for the related identifier (eg doi.org/10.21966.gcqh-4z26)
• A drop down text box for relatedIdentifierType with the option for DOI and URL and perhaps other Persistent Identifiers (PIDs) noted here
• A drop down text box for relationType with at least these types: 'IsCitedBy' and 'Cites' for discoverability, IsPartOf and HasPart for aggregation/subsetting, and IsVersionOf/IsPreviousVersionOf/IsNewVersionOf for versioning, IsIdenticalTo so that we can manage issues where multiple PIDs/DOIs exist for the same resource, or any / all of the relationTypes indicated here

I like how the 'Associated Datasets' would look in your CKAN example, but I'd call it 'Related Identifiers' because you can relate to a number of different resource types (Dataset, Journal article, Report, Software, etc.) And rather than listing the UUID from datasets just in CIOOS, it would be really nice to use DOI Content Negotiation from crosscite to display a citation.

Lastly, I'm unsure if there's a requirement to use the ISO Associated Datasets concept and just map to the DataCite schema for when we export to the DataCite.xml or if we can find a place for the DataCite RelatedIdentifiers elements directly in the ISO XML... Hoping you (@fostermh) and @n-a-t-e can help there.

[Br-Johnson]

In our recent Hakai code sprint (Jan 23-25, 2023)we talked about starting simply by including a section in the Resources tab of the metadata intake form to simply add URLs of relatedIdentifiers with some basic relationTypes.

[Br-Johnson]

Code sprint 4 update (Nov 20., 21st.)

We decided to implement something very similar to the DataCite GUI for relatedResources in to the Hakai metadata intake form:

• Related Identifier field will most often be DOI or URL. Could regex to determine the next field which is Related Identifier Type. Though support for all identifier types is wanted.
• Offer as full range of DataCite Relation Types as possible far as they can be mapped to ISO relation types. Keep both direction options if possible ie cites and isCitedBy for eg. Need to map relation types. See https://github.com/HakaiInstitute/hakai-data/issues/53
• Allow as full range of DataCite Resource Types as possible as far as ISO fields can be mapped to DataCite fields. See Option to manually change resourceType in citation #248

We want to be able to relate resources from either resource, but relating from both is not required. @fostermh will workout how to display related resources in both resources in CKAN at a later date in a different issue.

[fostermh]

explinations of related identifyer types on datacite https://support.datacite.org/docs/schema-optional-properties-v43#section-12-a-related-identifier-type

[Br-Johnson]

@fostermh When can I find the ISO list of relation types?

[fostermh]

https://wiki.esipfed.org/ISO_19115-3_Codelists#DS_AssociationTypeCode

[fostermh]

Screen shot for context.

What other have to say regarding 'Associated/Related Resources' aka the 'Related' tab which goes to MD_AssociatedResource in the ISO standard

• https://wiki.esipfed.org/MD_AssociatedResource
• https://wiki.earthdata.nasa.gov/display/NASAISO/Related+Resources
• https://icsm-au.github.io/metadata-working-group/defs/AssociatedResources

also from https://wiki.esipfed.org/MD_DataIdentification
The citations and identifiers of associated resources, such as projects and documents.

Vs

the 'Resources' tab which goes to MD_Distribution in the ISO standard

• https://wiki.esipfed.org/MD_Distribution
• https://wiki.earthdata.nasa.gov/display/NASAISO/Related+Resource+References+in+CMR+Metadata
• https://icsm-au.github.io/metadata-working-group/defs/DistributionInfo.html

To me these two areas are very different.
'Resources' is for providing information by which one can access the resources described using both online and offline access methods, contacts, and instructions. Where as 'Related' is for indicating an association between resources and records related to the resources described in this metadata record.

We can absolutely merge these tabs together but I think we need to make it very clear to users which option they are picking.