metadata in link json

[stuarteberg]

When managing collections of neuroglancer links (as JSON documents), it would be convenient if I could sneak in a bit of metadata for myself. I wouldn't want the metadata to be actually used by neuroglancer in any way, but I would want it retained in the JSON state (and URL).

For example:

{
  "metadata": {
    "link-created-by": "bergs",
    "link-creation-date": "2025-02-10"
  },
  "title": "my dataset",
  "dimensions": [...],
  "layers" [...],
  "layout": "4panel"
}

(I have additional metadata fields in mind that I won't bother explaining here.)

Would it be possible to permit a schemaless user-provided metadata field in the neuroglancer JSON state? (I don't have an opinion on the name of the key... metadata or user-defined-metadata or something like that seems fine.)

cc: @olbris

[joshmoore]

👍 Or the Zarr-ish attributes 😉

[fcollman]

I think ignored when parsing on initial loading makes sense.. but persistent across whatever changes are made in the UI? this seems like a bad idea as users might not be aware that this metadata exists and then start sharing links after fundamentally changing something about the link that the person who put the metadata into the json was expecting to be there.

Can you elaborate a bit on the use case for persisting metadata in the json state?

[stuarteberg]

I think ignored when parsing on initial loading makes sense

Indeed, it appears that unrecognized keys are currently ignored by neuroglancer anyway. So maybe I don't need any special feature, other than for someone to "bless" a particular key name (or prefix?) that is guaranteed not to become reserved in the future.

but persistent across whatever changes are made in the UI? this seems like a bad idea as users might not be aware that this metadata exists and then start sharing links

Yeah, that's a fair concern, and it might be enough to sink this proposal. We could start inventing mitigations (e.g. I could insert a checksum of some sort in my own metadata, or neuroglancer automatically adds "stale": true to the metadata field), but that adds complexity.

Can you elaborate a bit on the use case for persisting metadata in the json state?

I admit that my main use-cases are achievable without persistence, as long as I can insert stuff into the JSON that will be ignored. But I think the power to persist one's own metadata might be convenient in some cases. It would allow for simpler provenance tracking without referring to a separate data source.

Just brainstorming -- the following are all variations on the same theme:

• Systems like neuprint or Codex are capable of producing neuroglancer views based on user queries. The resulting neuroglancer view might contain only static precomputed:// or local:// sources, but it would be nice to preserve the query was used to produce that view.

• Similarly, suppose I have some automatically generated local://annotation layers which flag a (modest) number of points in a volume. If I want to store the parameters which produced the annotations (for provenance tracking or debugging), I could insert them into the layer name. But that gets unwieldy if there are a lot of parameters. (I suppose one could also sneak them into the annotation shader as a comment.)

• One can imagine simple DIY review protocols in which each review "task" is a programmatically generated neuroglancer link. For provenance and debugging purposes, it might be convenient to store info about how/why the task was generated, or at least an ID of some kind. Maybe it would be sufficient to store the task ID in the title, but that is arguably a bit ugly.