Category: техника

Category was added automatically. Read all entries about "техника".

2021 год
  • ailev

Как отражают множество viewpoints в ISO 15926

Для того, чтобы объединять veiw (множество групп описаний), которые появляются в силу наличия множества методов описаний (viewpoints) и неминуемыми различиями в терминологии и акцентах представления объектов реального мира, в ISO 15926, принят подход 4D extensionalism: в каждой из групп описаний описывается свой собственный объект (со своими описаниями, именами, отношениями и т.д.), но: если оказывается, что у двух индивидов экстенты (длина, ширина, высота, протяженность во времени) одинаковы – то это один и тот же объект, несмотря на разницу имён и разные описываемые отношения этих разноимённых объектов. Так, если «комплектующее с номером из функциональной схемы P101» из технологической группы описаний совпадает с «предметом снабжения с серийным номером #123» из группы описаний поставки, то это один и тот же насос.

Это типичная ситуация, когда речь идёт о жизненном цикле оборудования, где каждая стадия -- это свой преобладающий cognitive framework (что подразумевает свой преобладающий viewpoint и поэтому уникальный для этой стадии view). Для отождествления разных описаний одной и той же единицы оборудования используются отношения TemporalWholePart (пример -- первая пара диаграмм из http://techinvestlab.ru/iso15926_sample_diagrams).

Как заметил Hans Teijheler, самым простой тест на соответствие духу ISO 15926 -- это поискать в результатах моделирования отношения TemporalWholePart. Если они не найдены, то скорее всего речь идёт о моделировании только одного view одного viewpoint для одной стадии жизненного цикла. Это непорядок, моделировать нужно для всего жизненного цикла, выполнять рекомендации ISO 42010 (в котором прописывается необходимость множества view и viewpoints для описания системы. Невозможно одним описанием адресовать сразу все интересы, ибо у стейкхолдеров самые разные интересы/conсerns, требующие самых разных представлений одного и того же объекта интереса).

Я пишу этот пост потому, что только за первую декаду февраля был втянут в разные дискуссии по этому поводу уже раза четыре. Это частое непонимание: как именно удаётся ISO 15926 объединять все эти такие разные viewpoints, какие для этого используются механизмы? Потому и удаётся, что были приняты соответствующие онтологические предпосылки (ontological commitments). 4D extensionalism победил среди конкурирующих вариантов после тщательного обсуждения командой инженеров, делавшей спецификацию ISO 15926.
2021 год
  • ailev

Синтаксис и семантика в .15926L

Disclaimer. В Части 2 довольно много информации по information_representation, representation_form и прочих связанных с репрезентацией информации (репрезентация -- это когда текст/код X выражает, репрезентирует, служит "вместо" объекта Y). Information_presentation тут главным образом относится к шрифтам, размерам и прочим характеристикам рендеринга репрезентации. Есть language, но о нем практически ничего не сказано кроме того, что это подкласс information_representation. А вот notation и syntax отсутствуют. Вдобавок в том, как именно кладутся information_representation на базовые типы EXPRESS и OWL можно легко запутаться. Когда мы говорим о том, что применяем "обратную польскую нотацию для выражений", непонятно, отражать ли это игрой разных representations или же речь идет о "просто ренедеринге" и нужно использовать presentation -- как я понимаю, у авторов стандарта в голове был презентируемый насос, а не "выражение". Суть disclaimer в том, что я таки не разобрался подробно в том, что Часть 2 говорит про особенности толкования работы с текстами.

Далее я использую "презентацию" для внешнего представления (с какой нотации-языка переводим) и "репрезентацию" (на какой язык представления переводим).

Слово для перевода презентации в репрезентацию -- "перевод" (а не трансляция, не трансформация, не компиляция, не макроподстановка, не расширение и т.д.).

Значительное количество случаев моделирования данных связано с переводом текстовых строк каких-то кодов в соответствующий набор шаблонов. Код -- это "запись на языке", а хоть и на естественном (всякие "definitions"), а хоть и на языке программирования (причем не только Prolog или Python, но и, например, онтолеты самой ISO 15926, если нам захочется описать конфигурацию какой-то федерации RDL).

Более простой случай кода -- это "кодировка". Например, типовой случай промышленного моделирования данных -- это отражение синтаксиса тега, представляющего многопозиционную кодировку (типа РТМ, KKS) или в более простом случае классификации в виде набора диапазона литералов типа кодов пищевых добавок http://ru.wikipedia.org/wiki/Codex_Alimentarius), а в простейшем случае "обозначений" (т.е. просто списка литералов, без "классификации", обозначения тут -- нотация с вырожденным синтаксисом).

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

Синтаксис -- это мереология для information_representation. Разные языковые сущности выражаются разными текстовыми паттернами. Все эти "блоки" и "пространства имён" -- это чистой воды мереология, разные варианты отношения указанной синтаксисом смысловой части и текстового целого. Парсинг -- это разборка текста на части, мереологически описанная операция.

Поскольку Часть 2 определяет мереологию, то нужно каким-то образом понять, как пересекаются мереологические (части и целого) классы и отношения с репрезентационными классами и отношениями. Мне кажется, что недостающие классы, отношения и выражающие их протошаблоны могут быть предложены нашим проектом .15926 для пополнения стандарта и существенно этот стандарт усилить. Это также будет шаг в сторону .15926L

Форма и содержание (синтаксис и семантика) тесно связаны. В деятельностном подходе эта связь означает, что для каждого элемента синтаксиса мы должны иметь деятельностную семантику (то есть значение элемента синтаксиса -- это что мы делаем для перевода презентации в репрезентацию). Это означает, что мы должны иметь не столько "форма связанная с содержанием", сколько "форма связанная с действием по переводу презентации в репрезентацию".

В современном компьютинге "переводы" обычно делаются с использованием тяжелого аппарата лексеров, токенайзеров, визиторов для обхода получившихся структур и т.д.). Нам бы нужно что-то попроще, но и помощнее. Мне кажется, что OMeta (http://tinlizzie.org/ometa/) как раз такой тип парсера, который непосредственно осуществляет такой перевод входного потока текста в действия по генерации выходного потока (а не в собственно выходной поток!), причем безо всех этих опосредующих перевод лексеров, токенайзеров, визиторов и т.д.. Действия же могут быть в том числе довольно сложными. OMeta -- это деятельностный (а не формальный, т.е. "чисто про форму") подход к синтаксису и семантике.

Синтаксис должен быть first class object. Синтаксис это и есть недостающая часть отношения для пары "презентация-репрезентация", а само отношение описывает собой "парсер-генератор" (переводчик, компилятор, интерпретатор, транслятор) для пары языков и и связывающих их правил (синтксических паттернов и требующихся действий). Следовательно, нужно как-то "вышить" необходимые шаблоны для представления этой языковой механики. Ежели мы идем в сторону "онтологического языка", .15926L, то (как минимум!) этот язык должен уметь описывать относящиеся к языкам и кодированию вещи -- включая мереологию кода. Оставим "исполнение" на потом, но вот парсинг кодировок лучше бы уметь представлять прямо сейчас.

Еще одно соображение, которое наталкивает меня на важность разбирательств с языковыми конструкциями -- это сам механизм шаблонов 15926. Моё чутьё показывает. что шаблоны -- это про язык (ибо это "макросы", традиционно работающие в целях "синтаксического усахарения" языка -- и именно это мы и слышим от создателей этого механизма: заботу о компактности и понятности представления кодов с семантикой 15926). То есть "синтаксис" и "нотация" в шаблонах много ближе к сути дела, чем может показаться.

Это всё нужно специально исследовать, и довольно быстро. Ибо какую-нибудь кодировку KKS мы можем "распарсивать руками", на ходу придумывая ее мереологию, или сделать сразу какое-то подобие OMeta (YACC/LEX не предлагать за древностью их концепции), чтобы задействовать ухваченное там знание о синтаксисе-семантике и деятельностном к этой сладкой парочке подходе.

Понятно, что этот постинг не столько про софт .15926, сколько про моделирующее усилие, необходимое для того, чтобы по возможности софт .15926 был написан с использованием той богатой структуры представления знаний, которую нам предлагает .15926 -- и тем самым усилие моделирования данных для computer science domain является хорошим шагом в сторону .15926L.

Широко простирает программирование/кодирование/планирование руки свои в дела человеческие. Поэтому нужно иметь возможность его онтологического описания. Если не мы, то кто? "Что есть синтаксис?", "что есть парсер?".