doc/METAMODEL/DATA

DATA Model

OSI (TCP\IP) for Data

• NETCONF/YANG - это как TCP/IP. То есть там и про NETCONF, и про YANG. Однако не только NETCONF.

"интерфейс протокол формат"

Protocol vs Interface

• https://asutpforum.ru/viewtopic.php?t=6521
  • Интерфейс - это физика. Клеммы, кабель, вольты, миллиамперы, омы.
  • Протокол - это логика. Байты, биты, форматы посылок.
• обсуждение:
  • Csv, json, xml, html, rdf turtle и др. - суть (категория) одна, а ярлычки разные. Или есть какая то их таксономия?
  • Суть абсолютно разная. Общее только то, что всё это - языки разметки [markup language] в широком смысле. Они розволяют сериализовать некоторую структуру данных в некоторую последовательность символов некоторого алфавита и десериализовать обратно. Первый - формат сериализации "таблиц", следующие два - форматы сериализации иерархических структур данных. Следующий - жаргонное название большого класса языков разметки гипертекста. Следующие - сериализации "триплетов".
  • Формализовать / форматировать структуру данных, описать контейнер данных, задать формат задания последовательности объектов / данных, другие названия "одного и того же". В том числе описание формата "последовательности" содержит и описание структур самих данных - табличная, иерархическая, триплет. Это все про структуру данных - как описание последовательности вписывания данных в некую запись (сериализацию). Не понятно почему "структура данных" (описание структуры) не подходит под все это. Слово "структура" - широкое. Протокол может быт на любом уровне - от физического и выше. Все обсуждаемые форматы - это протоколы одного уровня, ниже которых лежит "условно физический" - кодировка типа кои-8 (аля osi). Можно про базовую триаду - по подробнее? Что в названии сущности содержится: protocol, language, notation - полагаю, что это условность (чтобы сокращение стало созвучнее). Ethernet - это протокол или интерфейс? В инете полно споров на эту тему. https://t.me/agirussia/111558
    https://schema.org/docs/developers.html
  • Нужно разрабатывать и выбирать способные коммуникативные фреймворки и модели. В данном аспекте УЭ предлагает модель "транспортного знаниевого стека" или "стека технологической поддержки [эпистемической] коммуникации". Статья на anticomplexity, планируется публикация. Эта модель сильно более методологически дисциплинирована, чем существующие в ныне модель Поланьи [Polanyi1966], c articulated & tacit knowledge; модель DIKW [Ackoff1989] (Data, Information, Knowledge, Wisdom); модель SECI [Nonaka1995] (Socialization, Externalization, Combination, Internalization) и ещё массы концептуальных эвристик вокруг соотношения "данных" с "информацией" и пр. Понятие "структуры данных" может быть спроецировано несколькими способами на данную модель. "Структура" — безмасштабное понятие, а "данные", хоть и интуитивно тяготеют ближе к южной части стека, но также могут иметь несколько интерпретаций.

Если отвечать на ваш вопрос, то в проекции на стек имеем независимый от репрезентаций и их синтаксисов семантический конструкт, и варианты транспортных синтаксисов: json, xml и пр. Их рефлексия как "языков разметки" нужна для использования этих синтаксисов человеками. Форматы их бинарной сериализации — для транспортирования по существующим сетям с их протоколами.

также

• https://github.com/bpmbpm/doc/tree/main/EA/DataQuality
• Книга: «Грокаем структуры данных» ; to grok - понять в деталях
• habr Сравнительная таблица структур данных

EAV

повтор
Entity — Attribute — Value

• Предельная унификация: программируем на языке бизнеса Предельная унификация a.k.a. IDEAV — хранение вообще всего как список Entity — Attribute — Value с дополнительным полем ID.
• SQL HowTo: разные варианты работы с EAV