Данное рассуждение было навеяно комментарием к заметке, посвященной реализации хранилища триплетов, поверх СУБД 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 – шаг вперед или два назад?
