https://github.com/nasa-gcn/gcn-schema/blob/fcf288bd8c418c915f291492f452d44e10648be4/gcn/notices/glowbug/alert.example.json#LL24C1-L39C1

Hi,

What was the reason to change the array of 15 with 15 named properties?

In the current schema the names can be anything? Shouldn't we change that?

Thanks!

@dakota002 somehow one of the core schema, DetectorStatus doesn't appear in schema browser, please fix it.

We noticed when Judy was presenting BurstCube PR.

With the new Localization core schema the error region is defined in the key ra_dec_error

The term ra_dec_error here is confusing for both producers and consumers, since for a circular error region with some error radius in angular separation the declination error is the stated error radius while the right ascension error is actually ≈ error / cos(dec).

The two suggested alternatives are:
event_id (to complement the use of event_name)
or
internal_id (to mimick the TNS nomenclature)

Design an Avro record schema to model position and attitude of a satellite in low-Earth orbit (i.e., spacecraft state vector). Draw upon FITS headers for housekeeping data used across multiple HEASARC-supported missions.

Putting together a test alert sender that will send IceCube track alerts, and found the schema, now with examples:
https://github.com/nasa-gcn/gcn-schema/tree/main/gcn/notices/icecube/amon
very helpful.

But as a producer of this information, it's not clear that all parts of some of the reused schema core components apply fully to the IceCube alerts.

For example: our initial localizations have a direction and circular errors at the 90% and 50% containment.
While the 'localization' item in the schema is a bit more complex. I CAN map the circular error onto an ellipse with equal major/minor axes. Can we include two containment levels? Right now our example has err50 added to cover this as a specialized field. That's fine if that's the preferred

Another is the FAR. We report a single FAR value in units of [yr^-1], but the Statistics schema is rather more complex. OK NOT to supply values when reporting? And we should match the units? Hz is doable but our FARs are few/year level.?

Thanks for guidance, will happily help update the icecube schema(s) moving forward.

Planning ahead for future instruments (BurstCube, Glowbug, StarBurst), design scintillator core type for common fields rather than GBM specific.

• File formats

  • Input in JSON or Avro or, convert between them?

    • But JSON doesn’t require type/description
    • JSON is very widely used
    • Avro is faster and has better compression - limitation given size of file

  • What will be done with VOEvent?

• Unified schema

  • Which schema registry?

    • access requirements for schema registry web UI
    • approval flow for PRs
    • If not, how do we validate schema? Don't we?

  • Would we allow submissions outside of unified schema?

    • we can push NASA missions to use it
    • write conversions for other missions?

• submission

  • NASA IT access + Client ID/token

  • kafka python binding?? - how does this work?

    • other languages?

• Archive

  • Convert historical archive into unified schema

    • GCN notices
    • catalogs?

  • new events to go into archive using unified schema DB

• Issue: attachments

  • Swift only mission that has them, archive is incomplete

    • Swift build their own TDRS products archive
    • SwiftTDRSreceiver program moved out of GCN

  • Healpix maps / Light curves / spectra / images / data files

    • URL at live mission archive?
    • attach to messages?
    • URL to somewhere on GCN?

  • Generate healpix map based on circular localization

    • push missions to do it themselves
    • we can do it as a fallback

Description

For Unified Schema we need to set-up rules for:
-getting approval from producers team for new version
-Tag the version: More rigid rules and examples for Major, Minor changes
-Announcement for New notice types

Acceptance criteria

• Add examples to the release instructions in the README file: new mission is a minor change, breaking change to an existing schema is a major change
• add this info to producer doc page

The links embedded in the "$id" field of the JSON notices does not exist, eg:
https://gcn.nasa.gov/schema/gcn/notices/swift/bat/guano/alert.schema.json

I think this is needed in order to progress with nasa-gcn/gcn.nasa.gov#764

I'm trying to design a new set of schema for BurstCube. Part of the validation script is checking if the id points to a real url as part of the schema browser. However, since it's a new schema, it doesn't, so it cannot pass validation.

✖ node validate.mjs:
error: gcn/notices/burstcube/Alert.example.json: can't resolve reference ../../core/Reporter.schema.json from id https://gcn.nasa.gov/schema/main/gcn/notices/burstcube/alert.schema.json
husky - pre-commit hook exited with code 1 (error)

Hi Vidushi,

Please clarify the examples in the descriptions to semi_major and semi_minor as well as why are they arrays? Thanks!

What if a core schema is updated to add a new record and the instrument-dependent schema doesn't include that record? Does the validation fail?

When can we expect the core schema to be frozen?
I see a few open PRs but don't have a good sense of the road map here...
Please let me know how i can assist in anyway.

LVK/RAVEN needs to know the schema of the alerts they will be listening to.
@Vidushi-GitHub @jracusin @dakota002 @lpsinger

Addition of release notes with tag version would be useful.

In order to be able to cite notice messages individually, we need to add a unique identifier for each message in the producer class. This could include a unique string for each producer than a alphanumeric string for each message.

Work out the proper way to handle 'null' entries. Ensure it works for strings, floats, ints, etc.

Work out if we need to provide a default value for each entry, setting them to obviously wrong values (e.g. a probability to -1)

The current validator.mjs code does not actually validate imported subschema fields when multiple subschema are referenced. Here is the code to reproduce:

{
  "$schema": "Test.schema.json",
  "ra": "this_should_break",
  "phi": 1
}

{
  "$id": "Test.schema.json",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Test schema",
  "description": "Test",
  "type": "object",
  "anyOf": [
    {
      "$ref": "https://gcn.nasa.gov/schema/gcn/notices/core/Localization.schema.json"
    },
    {
      "$ref": "https://gcn.nasa.gov/schema/gcn/notices/core/Alert.schema.json"
    }
  ],
  "properties": {
    "phi": {
      "type": "number",
      "description": "Angle between source location in azimuth measured from +x axis counterclockwise, to +y axis, range 0 - 360 degrees [deg]"
    }
  }
}

node validate.mjs should fail with "error: Test.example.json: must be number" but it does not.

Also, the current validate.mjs does not allow the use of unevaluatedProperties": false, which is useful for checking for fields that should not be present. I believe this may be related to the use of the $schema field within the alert. When validating with jsonschema I needed to pop the $schema field before the validation step to avoid mistaking it for an unevaluated property.

Why is datetime_of_notice in the Alert.schema.json not consistent with the other parameters naming here:
"alert_tense" "alert_type".
Should be "alert_datetime" (as it used to be!)

We need a way for healpix maps to be hosted on GCN somewhere, and include links in schema. Or the links could be to outside servers, but would be cleaner to be hosted by us.

Some of the fields in the core schema are high-energy instruments specific,
e.g. energy is in keV, and T90 duration is high-energy specific.
We need to work out more generalized units which include optical, radio, etc.

Additionally, required fields needed to be updated.

Description

Automatically request reviews from mission points of contact for changes that affect contributed mission schema.

Acceptance criteria

• Automatically request reviews from configurable points of contact when changes affect a given file. Use GitHub CODEOWNERS mechanism if possible.
• Automatically request reviews from above points of contact when a changes are made to a schema that is referenced by the given file.
• Repair, replace, or delete the broken review request workflow, https://github.com/nasa-gcn/gcn-schema/blob/main/.github/workflows/review.yml

We will start sending second copies (and eventually more feature filled) of the IceCube Astrotrack Notices via GCN Kafka. In GCN classic, these are sent via AMON, but will not be going forward.

Any concerns if I move these out of icecube/amon to icecube/ ?