Обсуждение

Про макросы в Gellish: Прежде всего, есть Gellish table в разных вариантах. Она уже мощнее стандартных шаблонов 15926-7, позволяя работать с разными сочетаниями опциональных параметров. Более хитрый вопрос - а где аналог возможности создания своих шаблонов? Про это в its_renssen_20050914.pdf есть раздел "3.6.5. Lists, tables and matrices". Но проблема в том, что там даётся общий метод. При этом реализация не определена. Ситуация в чём-то похожа на 15926-8, в которой пока нет места аксиомам 15926-7. Однако, у есть хотя бы реализация в 15926-7 (на уровне FOL), что служит отправной точкой для наших собственных разработок. В случае Gellish пришлось бы значительно больше писать от себя (а затем предлагать для внесения в TOPini, возможно).

Пока есть как минимум три варианта "новых отношений в ISO 15926": а) брать HQDM у Мэтью Веста (она уже отмэппирована в ISO 15926, но Мэтью утверждает, что понятней инженерам) б) отмэппировать отношения Gellish в) продолжать развивать "родной" набор шаблонов, додумав какую-нибудь табличную форму записи a la Gellish, т.е. отказавшись от формы "имяотношения(роль1, роль2, роль3,...)" в пользу хотя бы "роль1 имяотношения роль2 роль3 ... .". Я в своем постинге имел ввиду случай в), который синтаксически был бы очень похож на Gellish как минимум для всех шаблонов с парой ролей, но был бы хотя бы чуть более высокоуровнев за счет возможности указывать бОльшее число ролей с одним именем многоместного отношения. Ужас ситуации в том, что от онтолога требуется слишком много знать: выучить семантику слишком большого числа онтологий, и их не путать. Это как несколько иностранных языков выучить (так, в Gellish только основных отношений 650 -- попробуй, запомни!). Вопрос в том, что бы сделать, чтобы этого делать не нужно было: брать из Gellish форму (способ выражения семантики-прагматики), но не содержание (собственно онтологию, набор связанных сущностей). Хотя и про набор связанных сущностей идут споры, и немаленькие (хотя бы с тем же FunctionalPhysicalObject против InanimatePhysicalObject).

Расширенные синтаксисы и таблички это DSL. Что удобнее - "function x y z" или "object method y z" - зависит от задачи. Заменяя везде одно другим мы можем только создать проблемы, а не решить их. В 15926-7 сделали один простейший случай пользовательских макросов, в Gellish недоделали другой. В реальном мире требуется много и разных, хотя терминология 15926 относит это уже к мэппингу. В Gellish лучше сделана система хранения фактов. Она именно для фактов (в отличие от аттрибутного подхода EXPRESS) и с нормальной реификацией (в отличие от OWL и любых других схем на базе RDF). Неудачной мне кажется излишняя многосинонимность (подобная проблема есть и в CYC). Именно с точки зрения практической работы и легкозапоминаемости. Однако, насколько я понимаю, случаи вроде ограничения свойства в классе (ядрёный шаблон с upper и lower bound в презентации Судоэкспорта) могут решаться в Gellish нативно, на уровне одного отношения. Короче, если про расширяемость, то поможет только свой мэппинг. А для сравнения upper ontology надо отмоделировать что-то реальное в 15926 и Gellish одновременно. Но таких примеров я пока не встречал.

Ну, я согласен, что проблему без введения какого-то модульного языка не решишь. К тому же монопарадигмальное решение (да еще такое экзотическое, как логика-на-макросах) будет всегда коряво в современном де-факто мультипарадигмальном мире. Нужно таки довести эту линию с мэппингом до логического завершения, но одной извилиной всё-таки думать о том, как нотационно поддерживать онтолеты/OIM/микротеории и прочую модульность -- понимаемую в языко-ориентированном подходе как модульность языка. Projectional editors vs OMeta-стиля, и далее со всеми остановками на интерактивном программировании и "непрограммерском программировании силами экспертов"...