информационные преобразования
За время обсуждений в этом коммьюнити и переписке несколько раз поднималась тема .15926L и его самоописания. Ситуация: мы знаем, как данный винтик представляется в ISO 15926 и .15926L, но чем по стандарту ISO 15926 будет "знание о знании", "знание об изменении знания" и другие языковые конструкции .15926L? При этом параллельно всплывает тема о разделении Language и Notation из ISO 24744, аналогов которому нет в *Information* понятиях ISO 15926 part 2.
Однако, даже для описания языков, с которыми происходит работа в .15926 сейчас, разделения Language/Notation явно недостаточно. Если не включать внутренние языки, специфичные именно для нашего проекта, то получаются такие цепочки преобразований (приведены только наиболее используемые):
(язык части 2|язык части 7|другие части|расширения и локальные онтологии на их базе)*(EXPRESS|FOL|OWL*RDF*(XML|SPARQL))
Где OWL, например, который в других условиях позиционируется как полноценный язык, для нас является низкоуровневой транспортной нотацией которую при правильных условиях пользователь и видеть не должен. А отношения между частью 2, частью 7 и локальными онтологиями представляют отдельный интерес, но пока не могут быть описаны в ISO 15926 по причине отсутствия терминов для их описания.
Таким образом от дуальности Language/Notation получается переход к трансляторам между представлениями информации. Где у каждого есть:
1. Свои области трансляции (синтаксис, семантика, прагматика, ...) по возможностям.
2. Области трансляции по факту применения в какой либо цепочке.
3. Направленность. Однонаправленнй, двунаправленный, иные случаи.
4. Отношения с другими трансляторами (словарь C это совмещение словарей A и B, транслятор H это последовательное соединение языка F с нотацией G).
5. Совместимость с другими трансляторами (появляется система типов).
6. ...
А любое изменение информации - тот же транслятор, у которого domain и codomain совпадают. Факт наличия изменения это факт применения такого транслятора, который может являться частью некой группы трансляторов (например, .15926 engine API).
На мой взгляд, подобное описание информационных преобразований по уровню значимости и уровню сложности разработки вполне сопоставимо с созданием ISO 15926 part 2. Но если что-то получается в этом направлении - есть смысл зафиксировать, тем более что наш проект даёт хороший исходный материал для размышлений.
Однако, даже для описания языков, с которыми происходит работа в .15926 сейчас, разделения Language/Notation явно недостаточно. Если не включать внутренние языки, специфичные именно для нашего проекта, то получаются такие цепочки преобразований (приведены только наиболее используемые):
(язык части 2|язык части 7|другие части|расширения и локальные онтологии на их базе)*(EXPRESS|FOL|OWL*RDF*(XML|SPARQL))
Где OWL, например, который в других условиях позиционируется как полноценный язык, для нас является низкоуровневой транспортной нотацией которую при правильных условиях пользователь и видеть не должен. А отношения между частью 2, частью 7 и локальными онтологиями представляют отдельный интерес, но пока не могут быть описаны в ISO 15926 по причине отсутствия терминов для их описания.
Таким образом от дуальности Language/Notation получается переход к трансляторам между представлениями информации. Где у каждого есть:
1. Свои области трансляции (синтаксис, семантика, прагматика, ...) по возможностям.
2. Области трансляции по факту применения в какой либо цепочке.
3. Направленность. Однонаправленнй, двунаправленный, иные случаи.
4. Отношения с другими трансляторами (словарь C это совмещение словарей A и B, транслятор H это последовательное соединение языка F с нотацией G).
5. Совместимость с другими трансляторами (появляется система типов).
6. ...
А любое изменение информации - тот же транслятор, у которого domain и codomain совпадают. Факт наличия изменения это факт применения такого транслятора, который может являться частью некой группы трансляторов (например, .15926 engine API).
На мой взгляд, подобное описание информационных преобразований по уровню значимости и уровню сложности разработки вполне сопоставимо с созданием ISO 15926 part 2. Но если что-то получается в этом направлении - есть смысл зафиксировать, тем более что наш проект даёт хороший исходный материал для размышлений.