Обсуждение

метафизика - это поиск фундаментальных онтологий - т.е. правильные онтологии - это желаемый результат некоего процесса.

Метафизика, скорее, про онтологические выборы (свойства онтологий), и онтологии она рассматривает больше как примеры. Сами разработки онтологий (в полном соответствии с осознанными выборами, о которых говорит метафизика) обычно делает методология -- ибо без наличия какой-либо (проектной, устремленной к цели) деятельности любая онтология бесплодна. Если ничего не хочешь с окружающим миром делать, то никакая онтология тебе не нужна, и поэтому неважно, хороша она или плоха. Датамоделлеры читают книжки по метафизике, делают метафизические выборы. А затем в рамках избранного подхода ваяют кривую онтологию. Я к тому, что "плохую программу можно написать и на Паскале", как когда-то говорили.

А я к тому, что на Паскале можно писать и хорошие программы - в принципе то есть. Но вообще-то, мне показалось, что вы о том, что после "языкового поворота" мы можем только интерпретировать язык и поэтому фундаментально можем получать "кривые" онтологии. На это есть аргумент, однако, что существуют "hard signifiers", которые выводят нас за рамки языка, а, следовательно, могут дать правильные онтологии.

Есть разные причины иметь кривую онтологию: -- плохие метафизические выборы -- типа 4D или 3D онтология. -- плохие онтологические выборы на самом верхнем уровне таксономии -- типа обсуждаемых в http://www.jfsowa.com/ontology/psl_pn.htm. -- несовместимость, дублирование, нестыкуемость выборов кучи онтологов, которых пустили "совместно редактировать" онтологию. Или, что то же самое, плохое качество онтологии, построенной автоматически по набору текстов, написанному профессионалами из какой-то тусовки. Ибо сколько людей, столько и онтологий -- и им вовек не верифицироваться, не валидизироваться, отладиться. Ибо "отладка онтологии" -- это еще придумать нужно, как. "ОК" для одного из соавторов часто будет "полным отстоем" для другого. -- даже думать не хочу о других причинах (например, прямые ошибки -- описки, забытые места, сбои при наборе ID. Мы уже нашли в Gellish несколько таких ошибок). Есть не один путь, а много разных способов сделать криво -- в рамках языка, или за его пределами.

Я вчера тоже морщил репу на счет как жить с кривизной онтологий. То что онтология должна быть заточена под конкретную цель, а под другую цель будет нужна другая онтология, мне было уже понятно. А вот как при этом интегрировать приложения заточенные под разные и противоречивые онтологии? Мне видится перспективным микромодельный подход, в данном случае, микроонтологический, т.е. нужно создавать много маленьких онтологий, каждая из которых будет стабильна с большой вероятностью. А софт соответственно нужно писать так, чтобы при обноружении противоречивости в какой-то из (микро)онтологий он продолжал работать, пусть и с ограниченной функциональностью. Создание такого софта это конечно тоже головомойная задача, но с применением декларативных языков программирования/DSL она doable. А в случае одной или нескольких больших по размеру онтологий, что делать совершенно не понятно. Либо окружающий мир принудительно форматировать под выбранную онтологию.

а при чём тут датамоделлеры? любой domain можно десятью разными способами замоделить, в зависимости от requirements. часто полдомена можно вообще выкинуть из модели, ибо эта половина в дизайнируемой системе не используется.

Датамоделеры читают книжки по метафизике. А те, кто десятью разными способами моделят любой domain обычно читают книжки по разным моделированиям, а не по метафизике.

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

я не понял ваш пойнт, поэтому повторю свой :) онтология не может быть кривая "вообще", она может быть кривая только в рамках конкретной модели, сделанной для конкретной системы.

>>Поигрался с онтологией, автоматически извлеченной из русской википедии. Можно ссылку, где она или на инструментарий, ее создающий?

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

Частная разработка одного из стартапов, меня пустили поиграться.

Общие стандарты это круто и правильно (сам хорошо понял на примере FIX'а Financial Information eXchange). Но они тоже не все проблемы решают. Скажем, пополнение общей онтологии - процесс сравнительно длительный. Для распределенных систем нужна идеология частичной несовместимости. Я недавно почитал OWL мануал, они там это явно упоминают, типа нужно заранее готовиться, что онтологии будут несовместимы. Мне микромодели/онтологии еще интересны тем, что они очень компактно описывают проблему. А размер тестов (обобщенно - усилий необходимых для валидации модели) вообще говоря растет экспоненциально с размером переменных. Т.е. я пока основной упор делаю на микромодели/онтологии, ибо они мне нужны, чтобы: 1. разобраться в предметной области/требованиях (самый лучший способ - составить онтологию/модель либо изучить существующие). 2. генерить из них код/тесты и т.д. Общие онтологии для этого тоже пойдут, но они должны быть высокого качества.

Общие онтологии в датамоделинге как раз не предусматриваются для разработки микроонтологий (хотя в CYC для этого немного другой подход -- они наращивают общее онтологическое тело каждым своим чихом). У датамоделеров как раз постулируется, что каждый разработчик приложения по необходимости разрабатывает свою компактную онтологию, и что мир устроен именно так, а не иначе. Но на следующем шаге возникает необходимость обмена данными между приложениями, основанными на разных онтологиях. И именно в этот момент возникает нужда в нейтральной (не общей! именно что нейтральной!) онтологии, обязательно содержащей в себе upper ontology, для того, чтобы отмэппить эти маленькие компактные онтологии между собой. Более того, мэппить нужно только то, что передается между системами, а бОльшая часть информации не мэппится вообще.

Ну мне такой подход и близок. Ибо, у меня есть задумки на тему, как автоматически сравнивать онтологии. И как писать софт, который бы самоконфигурировался, т.е. на основании выявленных различий решал, может ли он с ними жить и в какой степени. Т.е. часть функциональности может отвалиться, часть может продолжить фунциклировать, если возможно преобразование данных (к примеру из int'ов в double'ы или наоборот).

Собственно, автоматическое сравнение поддерживают ризонеры для OWL DL, она специально для этих целей и создавалась.

Ну, само сравнение онтологий при мэппинге делается вручную. А вот сам софт мэппинга - он один и тот же на все. Выигрыш в том, что ручное сравнение делается только между каждой микроонтологией приложения и нейтральной Главной онтологией один раз, а вот затем мэппинг идет между любыми микроонтологиями (из, например, двух-трех десятков на среднем предприятии) автоматически, многократно и по потребности. При добавлении к этой уже работающей системе новых приложений с их микроонтологиями, для каждого из них делается однократное сравнение, а затем оно обменивается данными со всеми остальными. В ISO 15926 результат называется "конфедерация фасадов приложений". Конфедерация -- это слабая "регистрационная" связанность (в отличие от федерации, подразумевающей центральную власть). Фасад -- это типовая морда (адаптер), которая одинакова с онтологической точки зрения для всех остальных приложений (то бишь выражена в понятиях Главной онтологии). А вот за фасадом творятся собственные делишки этого приложения в его любимой микроонтологии.

Увы, все эти усилия тщетны, если есть синонимия и гомонимия. Или же вам придется честно втыкать в микроонтологии все понятия в какую-то общую upper ontology -- но тоже с ненадежным результатом. Объединения онтологий ведь для разных целей существуют. Для онтолого-исследовательских целей можно объединять хоть ужа с ежом, и внимательно изучать получившуюся колючую проволоку. А если вам нужна интеграция данных, то нужно не объединение, а отображение (мэппинг).

Полностью ручного мэппинга не избежать, это так. Но скажем, если у меня замэплены проперти или они общие, то классы, определенные в логических выражениях относительно комбинаций свойств, можно сравнить уже автоматически (при некоторых ограничениях на механизмы комбинирование, даже за разумное время :)).

можете посоветовать какое-нибудь онлайновое чтение по теме?