Условный yaml  файл как-то так может выглядеть

&transfer:
  - yes
  - no

&direction:
  - up
  - down
  - right
  - left

movement:
  - *transfer
  - *direction

По метаданным нужно иметь возможность проверять наличие этих признаков в данных

Просто описание для бинарных признаков можно сократить до true/false или проверочного бита (не надо писать yes / no).
Для несовместных многозначных описание = список key-value (имя признака - уникальное значение).
А для комбинированных нужно указывать внешние маски каждой несовместной группы, если несколько групп кодируются в пределах одного 32-битного значения.

Хм.
Ну, всё-таки вопрос, что предполагается с этим добром потом делать.

Например, описание через маски нужно если есть жёсткие ограничения по памяти. Ну, то есть потенциально может конечно скорость где-то вырасти, но это не факт.

Про бинарные признаки то же самое - конечно можно их свести к true/false, но можно этого и не делать, а оставить например всё в UInt8. Да, в 8 раз менее эффективно по памяти, зато более универсальная конструкция.

Ну, то есть если известно, что количество категориальных признаков не превышает 256, то вполне можно всё кодировать просто байтами. Неэффективно по памяти, зато удобно для оперирования.

Если у вас не гигабайты данных, то это вполне ок подход.

Ну и кстати обычный, но важный вопрос - эта схема хранения, она read only или read/write? То есть предполагается ли изменение данных после их формирования?

Насколько я знаю, read only схемы обычно более компактные по памяти можно делать, если это очень критично.

Грубо говоря, если схема read only, то можно сделать какой-нибудь простой формат хранения, а поверх него запустить in-memory zip (или любой другой архиватор). И вытаскивать данные распаковкой нужных кусков.

Тогда получится достаточно маленькое по объему памяти хранилище данных, но с медленным чтением и практически невозможной записью.

То есть, предлагаете разделять комбинированные группы на отдельные uint8 поля, и одно такое поле может кодировать только одну несовместную категорию до 256 значений?

Ну паковку можно добавить, если к примеру hdf5 использовать для хранения.

Скажем, сформированные данные read-only, но поверх них надо считать дополнительные данные, которые read-write.

Ограничения по памяти - это скорее касается формирования данных, да и удобнее во время формирования использовать одно поле и писать в него отдельные биты, а не заводить кучу разных полей.

Что потом делать - ну фильтровать, например, по значению признака.

В общем, я бы предложил всё-таки сначала не мучаться, а использовать базовые конструкции: вектора и словари.

А потом уже, когда с этими структурами будут написаны все необходимые алгоритмы и сформулированы требования, что от них нужно, вот тогда только заняться оптимизацией.

Просто для векторов и словарей фильтрующие функции уже написаны и не надо изобретать велосипед, можно сфокусироваться на реальной задаче.

Не могу не поделиться, очередной блог с картинками от кормуллиона

https://cormullion.github.io/pages/2020-09-22-depth/index.html

Красиво!

Кстати, по поводу Pluto. А никто с ходу не знает как там увеличить ширину ячеек с кодом? Очень раздражает что под них только треть страницы по ширине отведена...

Т.е. оно вбито в css 🙁 Надо покапаться в исходниках, возможно есть возможность перебить ее кастомными стилями