Что-то про онтологии на примере. Смотрите, сначала строим формальные схемы по тому, что мы выделили в онтологиях
 Скачать 472.06 Kb.
|
|
Сейчас я вас постараюсь распутать на примере трёх онтологий из одной области, которые потом в идеале совмещаются в одну большую мультиаспектную онтологию и всё красиво складывается. Помните пример с умными теплицами? Вот его рассмотрим более подробно. Я говорила на паре, что там может быть разделение на три части: сам продукт, его экосистема и управление данными. В этих терминах и продолжим дальнейшее рассмотрение. Смотрите, сначала строим формальные схемы по тому, что мы выделили в онтологиях: 1. Это онтология части «продукт». Тут мы видим, из чего он состоит – его подклассы, и то, чему он принадлежит – это ещё дополнительный класс, с которым продукт надо будет связать. То, что «продукт имеет» - это связи через object properties. Те овалы, что справа – это экземпляры (individuals by class) классов «температура», «площадь», «мощность обдува». От парка, кстати, типы конфигурации тоже будут экземплярами. А то, что bool – это просто тип данных для отношения укомплектованности.  Тут вроде понятно. Даже относительно читаемо. Часть парка – функциональная связь, значит и «продукт является частью парка» и «парк содержит продукт». Всё здорово. Такая схема вполне рабочая. Можно задать параметры через правила, которые мы будем потом писать, что если, например, у нас высокая мощность обдува и большая площадь, то эта теплица для типа конфигурации «колхоз». Температуру можно использовать для каких-то выращиваемых культур, если такое ввести. И так далее. Дальше примерно по этой же схеме изображаем остальные онтологи 2. например, про управление данными В  роде тоже понятно. Тут что-то где-то имеет – это отношения между классами, а тип набора данных – это экземпляры.3. и про саму компанию в целом М  ы называли эту часть «экосистема». Тут вы, конечно, можете смотреть на своё усмотрение. Кстати, то, что набор данных – это как раз то, что мы связывали на паре с вопросом: а надо ли вообще продавать человеку нашу теплицу? Берем тип данных, чекаем по нему всякие нужные нам вещи, и говорим (по схеме слева): мы знаем, что у нас всё ок с наполнением у покупателя (и дача есть, и ПО для умной теплицы, и ещё какие-то приблуды), потом ещё смотрим, есть ли вообще у нас конфигурация нужной вещи в парке (это первая онтология была, мы там как раз эти условия задавали), и вообще чётенько, можно в продакшн и покупателюПримерно так строится. Если вы запутались с вашими онтологиями, попробуйте их по такому же принципу разрисовать. Так должно стать понятнее =) Тогда первая онтология в протеже вообще не сложно делается, можете попробовать сами. А так, я вот пониже опишу: 1. создаем классы. Это наши зеленые квадратики  Что-то такое получаем. Мы это на паре делали Потом надо бы создать отношения между частями продукта и парком с продуктом.  Вот так прокликиваем для продукта все отношения в Subclass (естественно, сначала надо создать их в Object properties). Получается вот так:  То же самое создаем для отношения между продуктом и парком. Уже даже на схеме что-то красивое получается. Если что, стрелочки двоятся, потому что синие – это отношения относительно иерархии классов, а коричневые – это предикатные отношения «имеет».  Формально, останется только собрать экземпляры для каждого класса, если они нужны  Кстати, экземпляры можно отобразить, если щёлнуть по классу правой кнопкой мыши и нажать Show neighborhood.  Теперь красота. Даже похоже на то, что у нас в самом начале сделано. Дальше, я думаю, сами наделаете дел =) Не забывайте побаловаться ещё с Data properties. Там типы данных можно выставлять, и что-нибудь ограничивать |