core:recording_id idea

[gmabey]

I'm building a separate database that would house results associated with SigMF recordings.
It would be convenient to be able to intrinsically (and, unambiguously) associate those results with a recording.
I see the DOI keys in global and in core: and I have never used them, but I don't think registering my recordings is the right approach.
What do you think about a global field that would normally be generated automatically by a recorder at the time it's created?
Could be:

• core:recording_id
• core:recording_uuid
• core:unique_id
• core:uuid

Basically, I'm looking for an analog to uuid in the annotations section, but at the global level. It could even be required (maybe in 2.0), but I suspect that won't happen.

[777arc]

Seems like a great addition to https://github.com/sigmf/SigMF/blob/main/extensions/traceability.sigmf-ext.md

[777arc]

I vote core:recording_id

[Teque5]

If we use core:uuid it implies a typical implementation like 00000000-0000-4000-9000-000000000000, which I like. On the other hand this may be a big can of worms because what is the standard way to store it (hyphens / no hypens / hex / octal / bin). I may have to research this a bit and think about the best approach.

[gmabey]

From what I saw of the advanced features of JSON schema-ing, there's a way to define "reusable types" -- such a definition (albeit complicated) would be applicable to both this new core field as well as to core:uuid over in annotations.
Also, (from what little I know of JSON validation) there's a definite philosophy in that arena that just because a document agrees with the schema doesn't mean it meets a particular standard. In the case of SigMF, an example of this is the concept that, within captures, a core:samples_start not be duplicated; it's not enforceable via JSON schema, but it still (should be) part of the standard. Likewise for core:samples_start being monotonically increasing through the array.
Applying this to UUIDs, the schema may insist on "string" but that doesn't mean it's a SigMF-valid document, which (should) require 00000000-0000-4000-9000-000000000000-esque string.

I was going to vote for core:recording_id but now that I realize that the term uuid is already explicit over in annotations, I think I'm more inclined to vote for core:recording_uuid.
In Monday's call, I also brought up a concept we dubbed derived_from which would be an array of "recording IDs" from which the current recording is derived.
I think that traceability:derived_from is a great destination for this concept, but that's just me.

[Teque5]

We discussed this again 2025-08-18 and our consensus was that

• We like a traceability extension to have a derived from uuid.
• We think uuid makes more sense in global than in captures, given current use cases.
• Glen and I like core:uuid in the global field.

@777arc let us know if you concur.

[777arc]

Yeah that all sounds good, I always preferred it in global as well