Is the tracking_id in global attrs applicable to obs4MIP datasets OR any data within ilamb3-data

[jitendra-kumar]

All obs4MIP data may be used as ilamb-data, but all ilamb-data may not be part of obs4MIP. What does the tracking_id being created by default in ilamb3-data refer/resolve to?

https://github.com/rubisco-sfa/ilamb3-data/blob/0129fdfedab4cff6dcd5c9054e048f84de11de12/ilamb3_data/__init__.py#L871C12-L871C27

[nocollier]

I don't think they are intended to resolve to anything--they are more akin to what UPS gives you so you can track your package and less like DOIs that resolve to something. The first part is meant to (somehow) reflect who issued the tracking_id but I am not aware of some registry that you can lookup these headers. For UPS they resolve to something because UPS stores it and provides you a way to lookup that unique ID. Some have argued in the past that we could just use the filenames without the suffix as they are unique and just about as long, and would lead to human readable ids.

For now, obs4MIPs peeps sleep better inserting the text that they probably do not understand and so we poop it out wasting a few bytes. It doesn't matter. I am not sure there is more to it than the above.

[msteckle]

@nocollier @jitendra-kumar Here is ODS 2.6 explaining why it is required for them:

Form modified to facilitate use by ESGF; tracking_id should be of the form hdl:21.14102/ (e.g., “hdl:21.14102/02d9e6d5-9467-382e-8f9b-9300a64ac3cd”). The tracking_id should be unique for each file published in ESGF. CMOR automatically generates a tracking_id. You can review the python built-in UUID library documentation here.

So it doesn't actually resolve to anything until it's published on ESGF I suppose. It's certainly not necessary for ILAMB, but the idea is that ILAMB data is formatted with the hope that it'll go in obs4MIPs, so I also don't mind the wasted bytes. We can take it out later if needed.

[msteckle]

@jitendra-kumar Should I mark this question as resolved? Thx.

[jitendra-kumar]

Yes sure.