Add attribute for associating RAs with deployments

[kknee]

Background: gliders related to NANOOS are not associated with NANOOS in the NCEI archive, as discovered by @emiliom. Users should be able to filter by RA and find associated gliders in the archive.

Proposed solution: use a global attribute to indicate which RA(s) should be associated with the deployment in the NCEI archive. Whether to use a new (e.g. ioos_regional_association) or existing (see options below) is still being discussed. @rsignell-usgs do you know if there is a global attribute already in use by the community to specify IOOS RA?

Potential existing global attributes include: contributor_name creator_institution institution naming_authority program project publisher_institution

[lukecampbell]

I think we're going to use a global attribute called ioos_regional_association. @kerfoot The problem with the existing attributes (above) is that they're already filled in on some set of our data already. The second problem is we have to strictly maintain a consistent non-duplicative set of valid RAs so that NCEI can correctly associate a record with the IOOS RA.

@mbiddle-nodc

[kknee]

it was @mbiddle-nodc that suggested we not use a new global attribute, but if that's the best/only way forward...

[emiliom]

Thanks all!

My broad suggestion would be to try to maintain consistency with the approach used with netcdf from fixed-platforms (moorings, etc), if possible. We have a very well developed approach for RA representation on the SOS/SensorML side of things, but I haven't kept track of the corresponding netcdf side of things; I'm not sure who the best person would be to consult -- maybe Kyle W. and Alex Birger?

FYI, on the SOS/SensorML side, we naturally were not strictly constrained to CF/ACDD, but the implementation strongly leverages well-defined and unambiguously parsed standards, encodings and vocabularies.

[lukecampbell]

This is more for attribution of a dataset, which is a bit different than the naming/scope of a platform's URN. There's several instances where more than one RA have funded a glider deployment, so we're working on a way to accommodate several use cases:

• Retain the original dataset's attribution through the acknowledgement attribute
• Retain the original metadata for institution, contributor, contributor role etc.
• Create a new way to convey an explicit mention of an RA, so that NODC may associate metadata records created for GliderDAC datasets which can be associated specifically with an IOOS RA.

We don't want to change what others have already provided, and we want to strictly control what goes into this new attribute so that it's machine parseable.

[emiliom]

This is more for attribution of a dataset, which is a bit different than the naming/scope of a platform's URN.

Just to clarify: What I referred to about the IOOS SOS/SensorML attribution of the associated IOOS RA is focused on dataset attribution, not the naming/scoping of a platform urn (I assume you're referring to the recent discussions about urn's). But again, I'm not saying that I'm certain that implementation can translate cleanly into what you're trying to do; just that it's worth exploring.

There's several instances where more than one RA have funded a glider deployment

Kind of nice to hear this! I figured this could be the case, but I didn't know for sure of other instances besides the glider co-funded by NANOOS and CeNCOOS!

[kwilcox]

I would advocate for a generic extension of ACDD that wouldn't be used by the providers already. That rules out contributor_*, publisher_*, and creator_*.

Maybe support?

support_name: cencoos,nanoos,ioos
support_type: ra,ra,federal
support_email: a@a,b@b,c@c
support_role: fiscal,fiscal,fiscal

[lukecampbell]

I like this as well 👍

[kerfoot]

@kwilcox A few questions/concerns with the solution you suggested:

1. The sole reason of originally deciding to use something like global:ioos_regional_association was in response to some concerns by providers to associate an IOOS RA with a deployment, if it applies. We certainly don't want to discourage groups from submitting data to the DAC if the deployment is not associated with an RA.
2. I'm a bit concerned that adding the 4 new attributes you listed will cause some confusion for data providers as they may seem to conflict with existing attributes such as global:acknowledgement, global:institution, etc.

Is there a big downside to just using global:ioos_regional_assocation? Will this prevent discoverability, etc.?

[kwilcox]

@kerfoot Using support_* is just a little more future proof if IOOS decides they want to start tracking other types of support. If we use ioos_regional_assocation it only solving the issue at hand. I agree that support_* is much more confusing for providers. I'll just start adding both!

[emiliom]

This was resolved, wasn't it? If so, can you point me to documentation describing what new attribute(s) to add and how to use it/them?

This issue is still open, so if it's resolved, you might want to close it. Thanks.

[emiliom]

Just pinging again to see if this issue was resolved, and if so, how. Thanks.

[kknee]

@emiliom not yet, but the plan is to use ioos_regional_association.

[emiliom]

Thanks for the update.

[kerfoot]

I've added the global attribute to the CDL, .nc and .ncml files:

https://github.com/ioos/ioosngdac/blob/master/nc/template/IOOS_Glider_NetCDF_v3.0-qartod.cdl