mirror of
https://github.com/bpmbpm/doc.git
synced 2026-05-05 07:09:14 +00:00
34 lines
5.9 KiB
Markdown
34 lines
5.9 KiB
Markdown
### DATA Model
|
||
#### OSI (TCP\IP) for Data
|
||
- [NETCONF/YANG - это как TCP/IP. То есть там и про NETCONF, и про YANG. Однако не только NETCONF.](https://habr.com/ru/articles/667440/)
|
||
|
||
"интерфейс протокол формат"
|
||
### 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](https://anticomplexity.org/metatekst-metatekstovyj-protsessor-i-genezis-tehnologicheskoj-podderzhki-znanievoj-kommunikatsii/), планируется публикация.
|
||
Эта модель сильно более методологически дисциплинирована, чем существующие в ныне модель Поланьи [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
|
||
- [Книга: «Грокаем структуры данных»](https://habr.com/ru/companies/piter/articles/954670/) ; [to grok - понять в деталях](https://ru.wiktionary.org/wiki/grok)
|
||
- habr [Сравнительная таблица структур данных](https://habr.com/ru/articles/955972/)
|