Anatoly Levenchuk (ailev) wrote in dot15926,
Anatoly Levenchuk
ailev
dot15926

Categories:

Синтаксис и семантика в .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.

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

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments