Alistair Miles

Hi @joshmoore, I would imagine it should be fine to include some JSON-LD within a zarr array metadata document. I have to confess I don't fully grok the JSON-LD syntax,...

Just following up on this... > (1) If/how to support storage implementations which have some "native" mechanism for storing metadata (e.g., N5's HDF5 backend). I'm currently thinking that it's not...

> As to using an alternative to JSON, we would be interested in this. In particular protobuf came up as an interesting option. Using protobuf it should certainly be possible...

Interestingly looks like Arrow are [using flatbuffers](https://github.com/apache/arrow/blob/master/format/Tensor.fbs). Flatbuffers seem easier to accommodate than protobuf because of the support for unions. I'm thinking we could keep JSON as the canonical format,...

Just to say I've done some work on the v3.0 core protocol spec in the development branch to provide a mechanism for alternative metadata encodings to be defined and used,...

> One immediate thought is that using a codec/filter (like for compression) to manage > the format of an object inroduces the same problem as with filters. Namely it >...

Hi Matthias, I may be missing something in your suggestion, but the way I've thought of it is that the type of storage is entirely hidden behind the store interface....

Hi @Carreau, I see where you're coming from I think, and these are valid considerations. I think we just need to figure out where they should live within the zarr...

Inferring the type of the store from a URL-like string would seem like a reasonable approach to me, and should work for at least some store types. It could get...

This is an intriguing use case and proposal! One quick comment re removing old data from the beginning of an array, there is an open proposal (https://github.com/zarr-developers/zarr/issues/267) which would enable...