Пара слов по поводу реализации онтологий поверх баз данных.

Данное рассуждение было навеяно комментарием к заметке, посвященной реализации хранилища триплетов, поверх СУБД  Postgress — OWLgress’ у.

Итак, онтологии, например, в представлении Description Logic (DL), и базы данных, например, реляционные(РБД),  представители различных подходов к моделированию, причем

логический подход (DL и др.логики) по определению плохо совместим с РБД, что составляет значительную проблему при отображении элементов логических рассуждений на  РБД и еще большую проблему во время их обработки.

Как можно решить эти проблемы?

По сути, как совместить несовместимое, и, как  это несовместимое эффективно обрабатывать? 😀

Рассмотрим,  объектный подход (классика ООП), как частный случай логического подхода. Сразу становится легче — объектный подход совместим с реляционным намного лучше.  Отображение объектов в  РБД уже реализовано десятком различных способов (это можно увидеть в различных ORM таких как hibernate, toplink и doctrine). Производительность решений на базе ORM  может быть весьма высокой (при правильном проектировании БД почти сравнима с производительностью  «native»   SQL-решений), и, конечно, удобство разработки.

Ну и что, скажете вы. В этом ну и что, есть маленький момент, при котором даже 20% потеря производительности при использовании ORM не важна.

А момент этот заключается в том, что  ORM работает с объектами!

А в основе онтологии лежит объектная иерархия — т.е объекты связанные между собой отношениями

Значит, можно эту иерархию естественным способом развернуть через ORM в РБД.

Но вот проблема объект онтологии это не объект ORM!

Как минимум потому, что свойства объекта ORM описываются внутри определения этого объекта, а свойства объекта онтологии, подключаются к описанию объекта из вне, реализуя принцип свойство-центричности (одной из центральных особеностей  SW как распределенного решения)

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

Но это не проблема для локальных нераспределенных хранилищ триплетов — в этом случае эту разницу можно скрыть 😀

а как это можно сделать?

можно сделать адресацию компонентов онтологии через пространственные координаты как в Oracle Spatial и осуществлять сборку объектов и их экземпляров непосредственно перед обработкой

а можно … (тема одной следующих заметок 😀 )

Но это не все…

Свойство-центричность и объектность онтологии это один из нижний уровень семантического веба.

Это Уровень RDF c RDFS.

Я знаю многих умников, кричащих, что RDF с RDFS это отстой. Есть же OWL!

OWL конечно есть. Только анализ многих  OWL онтологий показал, что паттерны моделирования, которые там используются, легко могут быть реализованы стандартными средствами RDFS!

А с другой стороны, мне понравились ряд OWL Full-ориентированных онтологий по содержимому совместимых с OWL Lite (хоть это и спорное мое убеждение). В этом аспекте, мне больше всего нравятся легковесные онтологии на OWL Full… Это же надо, именно для представления легковесных онтологий (чуть ли не для простейших таксономий ) и  был создан OWL Full?! 😉

Действительно важным является то, что на основе RDFS  логический вывод будет крайне примитивным, но зато и более производительным. Таким образом, расширяя современные ORM  средствами поддержки  RDF/RDFS мы по сути создаем Semantic ORM. Далее, необходимо расширить набор отношений, поддерживаемых Semantic ORM до уровня OWL — буду еще на эту тему рассуждать…

PS Вот так и определился перевод какого стандарта будет следующим  — Профили OWL 2.

SPARQL PROTOCOL и SPARQL готовы, как только переведу их из дока  в соответствующую форму  W3C, опубликую.

PPS  Semantic ORM — шаг вперед или два назад?  😉


Понравилась статья? Поделитесь с друзьями!


12 Responses to Пара слов по поводу реализации онтологий поверх баз данных.

  1. PavelK:

    Я думаю, для начала надо определиться, что имеется в виду под «реализацией онтологий поверх РБД». OWL-онтология — это совершенно плоский набор аксиом, который замечательно сохраняется в любой БД, как в реляционной, так и в RDF store.
    OWL Full не был создан для представления легковесных онтологий. Он был создан.. ээ.. как бы получше выразиться… потому что его не получилось не создать :) Я согласен, что экспрессивность многих OWL-Full-онтологий является следствием лишь криворукости их создателей, но насчет RDFS — это слишком сильное утверждение. Для легковесных онтологий есть DL-Lite (т.е. OWL QL), а также EL++, в котором лог. вывод работает за полиномиальное время (даже для полной классификации).
    PS. Насчет OWL Full рекомендую прочитать обсуждение в public-owl-dev [1]. Оно многое прояснит.
    [1] http://www.nabble.com/Some-basic-questions-about-OWL-Full-to13351596.html

  2. PavelK:

    Кстати, к вопросу о легковесности, забыл сказать, что вывод в RDF(S) как раз NP-complete [1]

    [1] Herman ter Horst, «Completeness, decidability and complexity of entailment for RDF Schema and a semantic extension involving the OWL vocabulary», Web Semantics: Science, Services and Agents on the World Wide Web, vol 3(2-3), pp. 79-115

  3. Что то статья с веб семантик не грузится…
    Интересно на доказательсто посмотреть NP-полноты…

    ведь применяя аналогичный подход, как альфа-бета отсечение в ИИ, можно устранить необходимость полного обхода графа онтологии, как в общем и при поиске по любой другой объектной иерархии. А устранив проблему полного обхода онтологии устраняешь и проблему с полнотой..
    Конечно профессору виднее, но мне кажется, что не все так категорично

  4. PavelK:

    А причем тут граф онтологии и его обход? Онтология обходится за линейное время целиком. А вот время лог. вывода в худшем случае всегда будет экспоненциально, как ты не бейся и какие отсечения не применяй.
    NP-полнота доказывается сведением по Куку проблемы нахождения макс. клики в графах (она как известно NP-complete).
    Разумеется, все не категорично. Я всего лишь говорил, что стремиться к RDFS в надежде упростить вывод — это не самый лучший вариант. Для этого были сформулированы специальные DL, которые проще за счет отсутствия RDF-ных bnodes. Вот в них и надо впихивать свои онтологии если возможно.

  5. Как раз к RDFS и не надо стремится, надо идти от возможностей RDFS к более сложным решениями типа OWL. Так и при создании средств для отображения онтологий в БД — сначала реализуем поддержку RDFS, как «ассемблера» cемантического веба, а потом наращиваем функционал средствами поддержки OWL конструкций

    насчет обхода графа онтологий —

    логический вывод, как набор связанных между собой элементарных действий, направленных на достижение какой цели, упирается в выполнение обычных операций поиска.

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

  6. PavelK:

    Поверь мне как человеку, неплохо знакомому с ядрами reasoner’ов: *не упирается*. Если алгоритм имеет экспоненциальную сложность, то оптимизация элементарных операций не даст тебе ничего. То, что ты говоришь, называется микрооптимизацией и ей занимаются уже в самую последнюю очередь. Но как бы ты там все не соптимизировал, если ты попадешь на сложный случай (а в NP-полных задачах такая вероятность есть всегда), то не поможет ничего.
    Другое дело, что OWL — это даже не NP-Complete. Это NEXPTIME (т.е на 2(!) порядка хуже чем NP). Т.е. даже если P=NP и то не поможет.
    Но мое возражение было связано с тем, что «обход графа онтологий» тут вообще не при чем. Экспоненциальный размер имеет не сама онтология, а структуры данных, которые строит reasoner у себя в памяти (так называемые tableaux). Их размер устранить *в общем случае* никакими «отсечениями» нельзя. Для этого применяют хитрые алгоритмы блокировки, но и они не всегда работают.
    А оптимизацией reasoning’а в RDF(S) вообще никто никогда толком не занимался, ибо нафиг не надо.

  7. PavelK:

    Забыл написать: примерно то, что ты говоришь, реализовано Ораклом в проекте OWLPrime [1]. Насколько я помню, он там и поддерживает RDFS + подмножество OWL (даже вроде подмножество OWL Lite), настолько маленькое, что полноты вывод удается достичь через forward chaining (с OWL такое не пройдет).
    Меня особенно смешит, когда эти ребята надувают щеки и говорят, мол мы работаем с онтологиями, которые Pellet не может классифицировать. Нельзя сравнивать полный вывод в OWL и вывод с помощью правил в OWLPrime, который никогда и ни прикаких условиях не будет полным в OWL.

    [1] http://www.w3.org/2007/OWL/wiki/OracleOwlPrime

  8. Конечно, на таких сложных по структуре исходных данных, как OWL, алгоритм будет иметь экспоненциальную сложность. Вот только как такой алгоритм на практике внедрять?
    Может надо переписать алгоритм с целью уменьшения сложности? 😉

    Это получается, что при прочих равных пользователь некоторой распределенной системы, состарится раньше чем прийдет ответ от системы, а может и не дождется вовсе. А кинуть это на уровень Веба, так ситуация будет еще хуже.

    Поэтому я понимаю ребят с оракла — у них решение, которое на подмножестве OWL развивает нормальную скорость при конечности времени вычисления. Это для академичного проекта не круто, зато применимо на практике.

    Мне кажется, что в твоих рассуждениях места RDF/RDF(S) нет, хотя OWL выражается в RDF через спецификацию отношений в RDF(S). Вот этой особенностью я и предлагал воспользоваться — мап пинг на уровне моделей делаем из RDF/RDF(S) в РБД, а потом добавляем поддержку нужных нам отношений OWL.

    PS Чесно говоря, алгоритмами логического вывода на уровне модели OWL я начинаю только заниматься, но вспоминая обработку логических конструкций RDF/RDF(S), не сведение их к объектным моделям, ведет к очень низким скоростным показателям во время обработки. А такое никому не надо — решение должно быть эффективным

  9. посмотрел я на OWLPrime — по крайней мере по заявленным возможностям выглядит OWLPrime не плохо :roll:

  10. PavelK:

    Я согласен, что каждой задаче — свое решение. Если можно реализовать онтологию на невыразительном языке, но позволяющем быстрый вывод — это *надо* делать (иначе нафига мы щас с стандартизацией профилей OWL мучаемся?).
    Ты главное пойми, что есть сложность *алгоритма*, а есть сложность *проблемы*. Так вот и RDF(S)/OWL — это просто NP-трудные языки и никакой алгоритм никогда в принципе _в_общем_случае_ не сможет гарантировать быстрый reasoning. Невозможно. Поэтому я и не очень люблю RDF(S) — с одной стороны он низкоэкспрессивен, а с другой — вычислительно труден. Непродуман. Поэтому ребята из C&P и делали Owlgres над DL-Lite, а не над RDF(S)++ или OWLPrime. Поэтому у них есть *строгая* гарантия производительности, в отличие от Oracle.
    Другое дело, что возможностей Оракла у них нет :(

  11. Nata_Ke:

    Насчет OWL Full и Protege: заметила, что, например, импорт онтологии верхнего уровня (DOLCE) плюс импорт еще нескольких OWLDL онтологий заставляют Protege честно признаваться, что, возможно, эта онтология — в OWL Full, хоть никаких конструкций не из OWL-DL нигде не использовалось. Выходит, «криворукость» создателей усугубляется особенностями поведения Protege :(

  12. Дело может быть не только в Протеже. Рекомендую прочитать [1], там Шон описывает типичные случаи нежелательного OWL-Fullness’a, а так же подергать species validator из командной строки Pellet’a, например.

    [1] Sean Bechhofer, «Patching Syntax in OWL Ontologies», http://potato.cs.man.ac.uk/papers/patching04.pdf

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


Ответить с помощью ВКонтакте: