Address issues pointed out in Issue #1230 in gcn.nasa.gov

[blaufuss]

Correct several issues in the example GCN notice pointed out in nasa-gcn/gcn.nasa.gov#1230

Additionally, we found a few other inconsistencies in our GCN notices not matching schema that will be addressed in production when this PR is merged and will close the issue at that time. These changes are included as well in the updated example as well.

These changes update the example GCN notice to match the advertise schema and match what we're actually sending
Highlighted updates to example include:

• incorrect schema url
• missing 'reference' tag.
• use ref_ID instead of ref_id, and clarfy the ref_ID we use includes the version info from the LVK alert.
• use locallization schema from core

[lpsinger]

The validation is failing. See https://github.com/nasa-gcn/gcn-schema/actions/runs/6237245824/job/16930405774?pr=106.

[blaufuss]

The validation is failing. See https://github.com/nasa-gcn/gcn-schema/actions/runs/6237245824/job/16930405774?pr=106.

I'm actually not sure how to use this reference field then. The LVK notices clearly have a number that is a string, see for example:
https://gcn.gsfc.nasa.gov/notices_l/S230918ae.lvc

"reference": { "gcn.notices.LVK.alert": S230914ak },

also fails.

Advice?

[lpsinger]

I think we need to change that field's type in the core schema to be either a string or a union between string and number. @Vidushi-GitHub, how would you like to proceed?

[blaufuss]

if a change like that gets into main, I can rebase the PR.

[Vidushi-GitHub]

Oh, Is it just reference in follow-up schema: https://github.com/nasa-gcn/gcn-schema/blob/main/gcn/notices/core/FollowUp.schema.json? Also, we have now created schema version, I doubt we should go with change in main as earlier.

[blaufuss]

Oh, Is it just reference in follow-up schema: https://github.com/nasa-gcn/gcn-schema/blob/main/gcn/notices/core/FollowUp.schema.json? Also, we have frozen the schema version, I doubt we should go with change in main as earlier.

That's the correct place. LVK alert "numbers" are actually strings.

[lpsinger]

Oh, Is it just reference in follow-up schema: https://github.com/nasa-gcn/gcn-schema/blob/main/gcn/notices/core/FollowUp.schema.json? Also, we have now created schema version, I doubt we should go with change in main as earlier.

There's no problem with changing the core schema; we'll just need to do a release with a major version bump (e.g. v2.0.0). See https://semver.org.

[Vidushi-GitHub]

Ok, the reference field in schema was created for atel/gcn circular/gcn notices offset number (though for notices we still don't have solution for message/offset number). For TRIGGER_NUM: S230918ae, ref_ID was designed with string type, for example the Fermi trigger number is present in description as a string. The current ref-ID contains both trigger number and type info, includes all useful information. Else with this change, the description of reference will also change. @jracusin please suggestion

[blaufuss]

Some context. We use both ref_ID and reference.

ref_ID for us here is a larger set of information on exactly which version of the LVK trigger we use, like:

"ref_ID": "S230914ak-2-Preliminary",

where we expected reference to be to the more generic trigger ID from LVK, here 'S230914ak'

Due to some bugs in our example and sending script this hasn't matched the planned schema, but if we need to tweak this on our side to better match the overall vision, we're happy to. Please advise

[lpsinger]

@Vidushi-GitHub, would you please fix this?

[Vidushi-GitHub]

Absolutely! @blaufuss suggestion is let's swap the values of 'reference' and 'ref_ID' to maintain consistent descriptions, where 'ref_ID' would represent the trigger number. We understand the need of pointing to specific notice, thus, reference can be { "gcn.notices.LVK.alert": S230914ak-2-preliminary }. Is it ok? I'll proceed with number to string conversion for reference.

[blaufuss]

I think Leo's suggestion was to allow the reference to contain either a string or a number and not change the definition of ref_ID. Neither ID we're including is a straight up integer number from LVK alerts... Erik

…

On Fri, Sep 22, 2023 at 4:13 PM Vidushi Sharma ***@***.***> wrote: Absolutely! @blaufuss <https://github.com/blaufuss> suggestion is let's swap the values of 'reference' and 'ref_ID' to maintain consistent descriptions, where 'ref_ID' would represent the trigger number. We understand you the need of pointing to specific notice, thus, reference can be { "gcn.notices.LVK.alert": S230914ak-2-preliminary }. Is it ok? I proceed with number to string conversion for reference. — Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFYG33SEJBTUDSWYWAXNMDX3XWNDANCNFSM6AAAAAA42KZQUI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- ------------------------------------------------------------------------------------ Erik Blaufuss email: ***@***.*** "Any chance collision, and I light up in the dark." ------------------------------------------------------------------------------------

[lpsinger]

@blaufuss, this branch has merge conflicts. Would you please fix them?

[blaufuss]

@blaufuss, this branch has merge conflicts. Would you please fix them?

I'm not seeing this. I just pulled in main to this branch this AM...

GitHub is telling me:

This branch has no conflicts with the base branch
Only those with write access to this repository can merge pull requests.

[lpsinger]

@blaufuss, this branch has merge conflicts. Would you please fix them?

I'm not seeing this. I just pulled in main to this branch this AM...

I'm seeing this on GitHub:

but I tend to forget that I can squash commits in GitHub. This should be no problem.