Аналоги Virtuoso

[Alexander Sidorov]

Подскажите, есть ли на рынке комплексные enterprise-решения с акцентом на семантику, подобные Virtuoso?

[Dmitry Ulanov]

OpenAnzo - http://www.openanzo.org/

AllegroGraph RDFStore - http://www.franz.com/agraph/allegrograph/

RDF Gateway - http://www.intellidimension.com/

AllegroGraph RDFStore

2009/12/20 Alexander Sidorov <alex...@gmail.com>

Подскажите, есть ли на рынке комплексные enterprise-решения с акцентом на семантику, подобные Virtuoso?

--

Вы получили это сообщение, поскольку подписаны на группу веб данных.
Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу webofdat...@googlegroups.com.
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу webofdata-russ...@googlegroups.com.
О дополнительных функциях можно узнать в группе по адресу http://groups.google.com/group/webofdata-russian?hl=ru.

[Alexander Sidorov]

Решения на базе реляционных СУБД видятся мне бесперспективными, поэтому Intellidimension я не рассматривал изначально.
AllegroGraph, насколько я могу судить, это "всего лишь" SAIL c бонусом в виде AGWebView. Пока не улавливаю сравнения с Virtuoso.

А вот OpenAnzo, кажется, больше похож на Virtuoso, по крайней мере некоторые enterprise-features заявляются. Хотя вот они в wiki пишут:
"At the center of the Anzo system is the Anzo store, a data source service capable of storing many millions of RDF triples in an underlying relational database (IBM DB/2, Oracle, PostGres,MS SQL Server, H2 and HSQLDB are currently supported)."
То есть он в принципе работает только с реляционными хранилищами? И совершенно непонятно, как у них обстоят дела с логическим выводом.

Еще хотелось бы узнать характеристики RDF Store и ризонера в Virtuoso. И есть ли где-нибудь сравнение между бесплатной и платной версиями?

21 декабря 2009 г. 0:31 пользователь Dmitry Ulanov <dul...@gmail.com> написал:

[Ivan Mikhailov]

> Решения на базе реляционных СУБД видятся мне бесперспективными,
> поэтому Intellidimension я не рассматривал изначально.

Хм, не знаю. Язык у RDF Gateway очень аккуратный, продуманный, а движок
они рано или поздно доработают (или чужой вставят :) Так что у них
неплохие шансы развиваться вслед за лидерами с неким фиксированным
временным лагом. Но для простых немасштабных задач штука очень удобная
уже сейчас (потому что учить почти ничего не надо), и свою дольку рынка
они вряд ли упустят.

> Еще хотелось бы узнать характеристики RDF Store и ризонера в Virtuoso.
> И есть ли где-нибудь сравнение между бесплатной и платной версиями?

Ризонер в Virtuoso почти отсутствует, он ограничен встроенной поддержкой
sameAs, подтипов и подсвойств. Зато RDF Store очень хороший по скорости
и масштабируемости, и очень хорошо выполняются SPARQL-запросы над
реляционными данными (в том числе над данными из других СУБД
организации). SPARQL расширен необходимой для BI функциональностью
(аггрегатные функции, подзапросы, транзитивные подзапросы и т.п.).
Платная Virtuoso Universal Server поддерживает виртуальную схему БД, в
бесплатной Virtuoso Open Source этого нет, это единственное различие.
Одновременно с версией 6 будет выпущена платная Virtuoso Cluster
Edition, она будет бесплатной только для некоторых наших партнёров (так
же как, например, сборка Virtuoso Universal Server для Amazon EC2 Linux
распространяется бесплатно, можно даже скопировать образ виртуальной
машины с предустановленной Виртуозой).

Соответственно, для enterprise-решений я бы рекомендовал установку
Virtuoso Universal Server на одну серверную площадку с уже имеющимися
СУБД, "в один свич" с ними или, ещё лучше, с отдельным быстрым
соединением. В такой конфигурации она может, например, показать хорошую
производительность на SPARQL-версиях запросов TPC-D на данных, лежащих в
"традиционных" СУБД и подключенных с помощью виртуальной схемы. Тут по
степени интеграции аналогов просто нет, причём имеющиеся серверы и базы
не надо менять --- для них Virtuoso ничем не отличается от других
ODBC/UDBC/IODBC клиентов. Кроме того, можно использовать распределённые
транзакции и репликацию, например, объединять SPARUL и SQL-DML в одной
распределённой транзакции с "честной" двухфазной фиксацией.

Всего наилучшего,

Иван Михайлов
OpenLink Software
http://virtuoso.openlinksw.com

[Alexander Sidorov]

Хм, не знаю. Язык у RDF Gateway очень аккуратный, продуманный, а движок
они рано или поздно доработают (или чужой вставят :) Так что у них
неплохие шансы развиваться вслед за лидерами с неким фиксированным
временным лагом. Но для простых немасштабных задач штука очень удобная
уже сейчас (потому что учить почти ничего не надо), и свою дольку рынка
они вряд ли упустят.

Да ведь движок - это лишь одно из следствий их Microsoft-ориентированного подхода. Могли бы они заменить хранилище на что-нибудь другое - думаю, уже сделали бы. А то забавная картинка получается... периодически кто-нибудь им в mail-list пишет: мол, я тут попробовал загрузить хоть сколько-нибудь серьезную онтологию - ваша софтинка не справляется, хотя такой-то аналогичный продукт работает довольно резво. На что они говорят, мол, у нас нет результатов сравнения с другими софтинами, но все должно быть хорошо.

Ну или взять ту же интеграцию. Virtuoso заявляет фичу "Mapping Relational Data To RDF with Virtuoso's RDF Views", Intellidimension - "Join relational and semantic data using T-SQL". Насколько я могу судить, речь об одном и том же (по крайней мере в первом приближении). И вот опять Intellidimension поддерживает лишь SQL Server (ключевое слово - TSQL). Я, конечно, понимаю: тесное сотрудничество с Microsoft, особые условия и все такое... но подобный подход существенно снижает возможности использования продуктов Intellidimension. Разработал систему на базе Intellidimension, пришел в организацию, а у них Oracle Enterprise/Posgres. Получается принудительная интеграция с переходом на SQL Server... хотя мне трудно представить это даже в масштабах средней организации.

Кроме того, у Intellidimension нет бесплатной версии, только 60дневный триал. Да и у меня на них давно уже зуб :) Я как-то просил академическую лицензию, а мне даже не ответили (хотя с того же email оправляли триальные серийники). Если бы послали - я б понял (хотя я не просто так написал: где-то встречал упоминания о том, что у них есть академическая лицензия), но когда просто игнорируют - хуже всего.

Вот в сторону OpenAnzo я обязательно гляну, а Intellidimension - нет-нет-нет.

Ризонер в Virtuoso почти отсутствует, он ограничен встроенной поддержкой
sameAs, подтипов и подсвойств. Зато RDF Store очень хороший по скорости
и масштабируемости, и очень хорошо выполняются SPARQL-запросы над
реляционными данными (в том числе над данными из других СУБД
организации). SPARQL расширен необходимой для BI функциональностью
(аггрегатные функции, подзапросы, транзитивные подзапросы и т.п.).

 

Звучит очень заманчиво: как раз то, что нам нужно.
Ну а насчет ризонера... я некоторое время назад (лучше поздно, чем никогда, да? :) ) пришел к выводу, что для большинства enterprise-приложений вывод таких базовых вещей, как sameAs, подтипов и подсвойств - то, что доктор прописал: бОльшая выразительность, как правило, не нужна. Зато в качестве бонуса получаем огромную производительность (стоит хотя бы сравнить OWLIM и Pellet).
Кстати-кстати. Хотел бы узнать мнение подписчиков webofdata по поводу недавно зарелизенного PelletDb. Для меня этот продукт - загадка. Pellet - это OWL DL ризонер с никакущей производительностью (которая ставится в жертву выразительности), работающий в силу используемых алгоритмов на одном ядре. Никак не пойму, какой толк от него в enterprise-секторе (Oracle как никак), ведь Pellet не предназначен для обработки больших массивов данных (в отличие от более низковыразительных ризонеров, заточенных под серьезные нагрузки).
Единственный плюс от использования Oracle, который мне виделся изначально: возможность вывода моделей, не помещающихся в память (даже если забыть о том, сколько у Pellet это займет времени). С учетом нынешней стоимости памяти не такой уж и большой плюс... но после прочтения pelletdb-whitepaper (http://clarkparsia.com/files/pdf/pelletdb-whitepaper.pdf) выяснил, что полноценной реализации этой фичи нет. Цитирую:
"When instance data is too large to fit into memory,
PelletDb can be configured to extract only the schema from Oracle Database 11g,
compute additional schema inferences, and save those inferences back to Oracle Database
11g. Oracle Database 11g can then be used to perform instance reasoning using the
schema inferences computed by PelletDb."
Какой-то винегрет получается.
 

Платная Virtuoso Universal Server поддерживает виртуальную схему БД, в
бесплатной Virtuoso Open Source этого нет, это единственное различие.

 

Посоветуйте хороший документик про виртуальную схему. Я так понимаю, работа с реляционными хранилищами через SPARQL входит в это понятие?

Всего наилучшего,

Иван Михайлов
OpenLink Software
http://virtuoso.openlinksw.com

[Ivan Mikhailov]

> Платная Virtuoso Universal Server поддерживает виртуальную
> схему БД, в
> бесплатной Virtuoso Open Source этого нет, это единственное
> различие.
>
> Посоветуйте хороший документик про виртуальную схему. Я так понимаю,
> работа с реляционными хранилищами через SPARQL входит в это понятие?

Виртуальная схема БД --- механизм, который делает таблицы сторонних
серверов БД доступными для SQL-запросов, как будто они хранятся в данной
локальной БД. То есть стоит оракл с таблицами ECRM..ORDER и
ECRM..CUSTOMER, рядом стоит DB/2 с таблицей PR..ADVERTISEMENT, и тут же
стоит Виртуоза, на которой админ выполняет операторы

ATTACH TABLE ECRM..ORDER AS MYORDER FROM MYORACLE;
ATTACH TABLE ECRM..CUSTOMER AS MYCUSTOMER FROM MYORACLE;
ATTACH TABLE PR..ADVERTISEMENT AS MYAD FROM MYDB2;

и после этого на Виртуозе можно выполнить, например,

SELECT ord.product, min(ord.reqdate), sum (ord.total), ad.title, sum
(ord.total)/sum(ad.total) as hype_to_effort
FROM ECRM..ORDERS ord,
ECRM..CUSTOMER cust,
PR..ADVERTISEMENTS ad
WHERE ord.product = ad.product
AND cust.id = ord.customer_id
AND ord.reqdate > ad.on_air_date
AND ord.reqdate < ad.stale_date
AND cust.country = ad.country
GROUP BY ad.title, ord.product,

Виртуоза выполнит нужное число нужных запросов к Ораклу и DB/2 и из их
ответов соберёт конечный результат.

SPARQL-BI виртуозы реализован как препроцессор над SQL. Соответственно,
SPARQL-запрос может быть вставлен в любое место в коде, где может быть
использован SQL-запрос, он может быть выполнен через любой интерфейс,
через который может быть выполнен SQL (в т.ч. через
ODBC/UDBC/IODBC/JDBC/ADO.Net и интерфейсные библиотеки Perl, PHP и
т.п.), он может получить доступ к любым таблицам, к которым есть доступ
через SQL. Если виртуальная схема есть (Virtuoso Universal Server), то
SPARQL может использоваться для доступа к сторонним серверам, если её
нет (Virtuoso Open Source), то только для доступа к локальным таблицам.
В обоих случаях SPARQL-препроцессор используется абсолютно одинаковый и
в обоих случаях он не знает, где именно хранятся данные.

[Alexander Sidorov]

Беру назад часть желчи в отношении Intellidimension. Как нельзя кстати, сегодня в их maillist'е:
Вопрос:
"Hi All,

Is possible to connect Oracle Servers using Intellidimension.Rdf.

Datasource.SqlDatasource?. I think that SQLDataSource from Intellidimension only work with SQL Servers."

Ответ:

"Hi Eduardo,

 Yeah, I think that’s the case right now.  The SqlDataSource is a port of the original Sql data service in RDF Gateway that did work with Oracle and others. But I recall that we ran into issues with the GetSchema method in ADO.NET not supporting the PrimaryKeys collection, so we had to go db specific to get that intormation – and so far, we haven’t done that for Oracle.

"

Все-таки работы в направлении расширения списка поддерживаем хранилищ (пусть пока и реляционных...) ведутся.

21 декабря 2009 г. 12:04 пользователь Alexander Sidorov <alex...@gmail.com> написал:

[Alexander Sidorov]

Правильно ли я понял, что в бесплатной версии доступен весь функционал Virtuoso, но только для работы с каждой базой данных по отдельности (без возможности интеграции на уровне запроса)?

21 декабря 2009 г. 13:56 пользователь Ivan Mikhailov <imikh...@openlinksw.com> написал:

[Ivan Mikhailov]

> Правильно ли я понял, что в бесплатной версии доступен весь функционал
> Virtuoso, но только для работы с каждой базой данных по отдельности
> (без возможности интеграции на уровне запроса)?

В бесплатной версии доступен весь функционал, но без соединений с
другими базами данных вообще. Virtuoso ведь и сама по себе "толстая"
RDBMS с SQL2000, процедурным языком и кучей расширений, не только
"пустая" middleware для доступа к сторонним базам.

[Alexander Sidorov]

Теперь понял. Спасибо :)

Тогда такой вопрос: сколько стоит средненькая конфигурация Virtuoso? Наверное, звучит вроде "сколько стоит квартира", да? :) Мне пока трудно подобрать критерии... но вот здесь (https://shop.openlinksw.com/shop.vspx#product) я выбрал Virtual Database и пощелкал по опциям - вроде бы получается терпимо. Правда, не могу понять, что в продуктах для покупки делают Relational Database, XML Database и т. д., которые, как мы выяснили, идут в комплекте с бесплатной версией?

Просто интересно, почему в таком передовом продукте до сих пор SQL2000? Переход на более позднюю версию нецелесообразен, дорог или, может, технически сложен из-за большого числа расширений?

22 декабря 2009 г. 2:34 пользователь Ivan Mikhailov <imikh...@openlinksw.com> написал:

[Ivan Mikhailov]

> Тогда такой вопрос: сколько стоит средненькая конфигурация Virtuoso?

Хм, я, оказывается, пропустил "косвенное" падение цен. Раньше опций было
две --- число соединений и число процессоров, ну и оптовые скидки на
большое число машин. Теперь можно урезать "старую" цену, выключая лишние
протоколы. Исполняемый файл в любом случае один и тот же, и это именно
один исполняемый файл, без IPC между компонентами (отсюда и скорость на
реальной нагрузке). Просто теперь лицензия стала более подробной.

> Правда, не могу понять, что в продуктах для покупки делают Relational
> Database, XML Database и т. д., которые, как мы выяснили, идут в
> комплекте с бесплатной версией?

Это опции лицензии, а не отдельные дистрибутивы или исполняемые модули.
Выключается кусок лицензии --- падает цена. Если версия бесплатная
изначально, то и цене падать некуда, и файла лицензии нет.

> Просто интересно, почему в таком передовом продукте до сих пор
> SQL2000? Переход на более позднюю версию нецелесообразен, дорог или,
> может, технически сложен из-за большого числа расширений?

Да что-то никто не спрашивает --- мы и не делаем. Тем более что в язык
добавлены и более поздние "куски": XML-функциональность Oracle, полные
rollup/cube, и ещё всякая мелочь.

Перед покупкой разумно запросить бесплатную пробную лицензию (вся
функциональность включена, столько соединений, сколько попросите, срок
действия один месяц). Можно аккуратно измерить фактические потребности и
убедиться в качестве техподдержки.

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

[Alexander Sidorov]

Это опции лицензии, а не отдельные дистрибутивы или исполняемые модули.
Выключается кусок лицензии --- падает цена. Если версия бесплатная
изначально, то и цене падать некуда, и файла лицензии нет.

Правильно ли я понял, что при покупке платной версии необходимо платить даже за те компоненты, которые бесплатны в Open Source Edition? Иначе как объяснить опции Relational Database и XmlDatabase, которые, по вашим словам, в полной мере входят в состав Open Source Edition.

Кроме этого, я не разобрался, какую опцию нужно выбрать, если меня интересует только RDF-хранилище с поддержкой RDF Views к внешним (по отношению к Virtuoso) базам.

Наверное, мне стоит написать в "Licence Terms Clarification"...


Созрел еще один общий вопрос. На схеме архитектуры Virtuoso (которая, к слову, впечатляет), значатся только сервис-ориентированные протоколы взаимодействия и ни слова о каких-либо фреймворках, лежащих на уровне выше и позволяющих представлять модель онтологии в памяти. С одной стороны, подобные фреймворки снижают универсальность системы (не напасешься их и под Java, и под .NET, и под C++), с другой, - писать парсер SPARQL, GData и т. д. не очень хочется.

Мне очень импонирует решение этой проблемы, предложенное AllegroGraph (http://www.franz.com/agraph/allegrograph/ag_client-server_arch-new.jpg). С одной стороны, у них есть низкоуровневые универсальные средства работы с сервером (тот же SPARQL), с другой, есть поддержка нескольких Java-фреймворков, а также самописные клиенты для C# и Lisp. Реализовано ли нечто подобное в Virtuoso?

[Ivan Mikhailov]

On Fri, 2009-12-25 at 16:40 +0600, Alexander Sidorov wrote:
> Это опции лицензии, а не отдельные дистрибутивы или
> исполняемые модули.
> Выключается кусок лицензии --- падает цена. Если версия
> бесплатная
> изначально, то и цене падать некуда, и файла лицензии нет.
> Правильно ли я понял, что при покупке платной версии необходимо
> платить даже за те компоненты, которые бесплатны в Open Source
> Edition? Иначе как объяснить опции Relational Database и XmlDatabase,
> которые, по вашим словам, в полной мере входят в состав Open Source
> Edition.

Я бы переиначил. В Open Source Edition мы бесплатно поставляем куски, за
которые в других версиях надо платить. Не будь бесплатной версии вообще,
схема лицензирования вопросов бы не вызывала, правда?

> Кроме этого, я не разобрался, какую опцию нужно выбрать, если меня
> интересует только RDF-хранилище с поддержкой RDF Views к внешним (по
> отношению к Virtuoso) базам.

> Наверное, мне стоит написать в "Licence Terms Clarification"...

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

> Созрел еще один общий вопрос. На схеме архитектуры Virtuoso (которая,
> к слову, впечатляет), значатся только сервис-ориентированные протоколы
> взаимодействия и ни слова о каких-либо фреймворках, лежащих на уровне
> выше и позволяющих представлять модель онтологии в памяти. С одной
> стороны, подобные фреймворки снижают универсальность системы (не
> напасешься их и под Java, и под .NET, и под C++), с другой, - писать
> парсер SPARQL, GData и т. д. не очень хочется.

У нас есть возможность прицепить непосредственно к процессу сервера
модули на Perl,PHP,Java и т.п. Они могут выполнять SPARQL запросы точно
так же, как любые SQL-запросы, через специальняй in-process client.
Напрямую в память сервера лезть нет практического смысла --- это очень
сложно даже в случае одиночной машины, не говоря уж о кластере.

>
> Мне очень импонирует решение этой проблемы, предложенное AllegroGraph
> (http://www.franz.com/agraph/allegrograph/ag_client-server_arch-new.jpg). С одной стороны, у них есть низкоуровневые универсальные средства работы с сервером (тот же SPARQL), с другой, есть поддержка нескольких Java-фреймворков, а также самописные клиенты для C# и Lisp. Реализовано ли нечто подобное в Virtuoso?

Единственная клиентская вещь, которая у нас есть --- OpenLink AJAX
Toolkit. Мы не хотим отбирать работу у наших клиентов ;)

Всего наилучшего,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

[Alexander Sidorov]

Единственная клиентская вещь, которая у нас есть --- OpenLink AJAX
Toolkit.

А вот и неправда :)
Как минимум, я нашел Virtuoso Jena Provider (http://www.openlinksw.com/dataspace/dav/wiki/Main/VirtJenaProvider#What%20is%20the%20Virtuoso%20Jena%20%20Provider). Или этот провайдер разрабатывает сторонними разработчиками?

Всего наилучшего,

Ivan Mikhailov

OpenLink Software
http://virtuoso.openlinksw.com

[Alexander Sidorov]

Ризонер в Virtuoso почти отсутствует, он ограничен встроенной поддержкой
sameAs, подтипов и подсвойств.

Нашел таки описание ризонера в Virtuoso (http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html). И правда, вывод довольно скромный. Интересно, чем это вызвано? Ведь те же AllegroGraph и BigOWLIM тоже ориентированы на производительность (а не на выразительность), но поддерживают более широкое подмножество OWL. Есть ли планы по расширению возможностей ризонера?

[Alexander Sidorov]

Единственная клиентская вещь, которая у нас есть --- OpenLink AJAX
Toolkit. Мы не хотим отбирать работу у наших клиентов ;)

Кстати, а какой протокол используется для модификации содержимого хранилища?

[Ivan Mikhailov]

On Fri, 2009-12-25 at 17:41 +0600, Alexander Sidorov wrote:
> Единственная клиентская вещь, которая у нас есть --- OpenLink
> AJAX
> Toolkit.
> А вот и неправда :)
> Как минимум, я нашел Virtuoso Jena Provider
> (http://www.openlinksw.com/dataspace/dav/wiki/Main/VirtJenaProvider#What%20is%20the%20Virtuoso%20Jena%20%20Provider). Или этот провайдер разрабатывает сторонними разработчиками?

Прошу прощения, я про
http://www.openlinksw.com/dataspace/dav/wiki/Main/VOSRDFDataProviders
забыл напрочь. Это наше, и действительно они "по ту сторону" соединения.
Написаны без моего участия, багов оттуда не поступают, ну я и забыл про
них.

> Нашел таки описание ризонера в Virtuoso
(http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html). И правда,
вывод довольно скромный. Интересно, чем это вызвано? Ведь те же
AllegroGraph и BigOWLIM тоже ориентированы на производительность (а не
на выразительность), но поддерживают более широкое подмножество OWL.
Есть ли планы по расширению возможностей ризонера?

Будут запросы --- будем расширять. С другой стороны, Ontotext на своих
слайдах показывает для Виртуозы очень хорошие скорости вывода при
загрузке. Они сами меряли, не знаю подробностей, но эксперименты тут:
http://www.slideshare.net/ontotext/reasoning-with-a-billion-of-linked-data-facts , слайд 7, по оси Y "Loading speed (K statements / sec)", если ваш браузер не покажет текст. И там на слайде хорошо видно, что чем толще вывод, тем медленнее. В любом случае есть более интересные расширения, напр. Federated SPARQL, которые будут пользоваться большим приоритетом.

> Кстати, а какой протокол используется для модификации содержимого
хранилища?

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

Всего наилучшего,

Иван Михайлов
OpenLink Software
http://virtuoso.openlinksw.com

P.S. Из переписки потом сможете склеить заметку "как я покупал Виртуозу"
для semanticfuture.net, или разрешить мне склеить заметку "как я
продавал Виртуозу" :)

[Alexander Sidorov]

Будут запросы --- будем расширять. С другой стороны, Ontotext на своих
слайдах показывает для Виртуозы очень хорошие скорости вывода при
загрузке. Они сами меряли, не знаю подробностей, но эксперименты тут:
http://www.slideshare.net/ontotext/reasoning-with-a-billion-of-linked-data-facts , слайд 7, по оси Y "Loading speed (K statements / sec)", если ваш браузер не покажет текст. И там на слайде хорошо видно, что чем толще вывод, тем медленнее.

Это никто под сомнение не ставил :) Было б иначе - не было бы RDFS+, RDFS++ и т. д. ризонеров: все бы поддерживали OWL DL и не жужжали. Хотя было бы не так интересно, да :)

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

[Ivan Mikhailov]

У нас есть выбор, что и в каком порядке делать, по всем пунктам, кроме
обеспечения масштабируемости: мы должны поспевать за ростом размера
"ядра" LOD. И, кстати, если вы будете обрабатывать тексты "о реальном
мире", а не узкоспециальные документы одного вида (налоговые отчёты
какие-нибудь), то локальная копия этого датасета вам может пригодиться
куда больше иного резонера. А датасет этот нынче под девять гигатриплов
размером ;)

Рассмотрите ещё такой вариант: статическое пополнение базы выведенными
фактами. Если сильный ризонер нужен для добавления недостающего в
WordNet или аналоге, то вполне возможно один раз помучить внешний
ризонер, запомнить результат в той же базе (м.б. в другом графе), и
закрыть проблему.

[Alexander Sidorov]

У нас есть выбор, что и в каком порядке делать, по всем пунктам, кроме
обеспечения масштабируемости: мы должны поспевать за ростом размера
"ядра" LOD. И, кстати, если вы будете обрабатывать тексты "о реальном
мире", а не узкоспециальные документы одного вида (налоговые отчёты
какие-нибудь), то локальная копия этого датасета вам может пригодиться
куда больше иного резонера. А датасет этот нынче под девять гигатриплов
размером ;)

Рассмотрите ещё такой вариант: статическое пополнение базы выведенными
фактами. Если сильный ризонер нужен для добавления недостающего в
WordNet или аналоге, то вполне возможно один раз помучить внешний
ризонер, запомнить результат в той же базе (м.б. в другом графе), и
закрыть проблему.

Да, я думал об организации чего-то вроде nightly reasoning. Хотя костыль, конечно... А нет ли (может, в планах) в Virtuoso возможности интеграции сторонних ризонеров?

Всего наилучшего,

Иван Михайлов
OpenLink Software
http://virtuoso.openlinksw.com

[Ivan Mikhailov]

> Рассмотрите ещё такой вариант: статическое пополнение базы
> выведенными
> фактами. Если сильный ризонер нужен для добавления
> недостающего в
> WordNet или аналоге, то вполне возможно один раз помучить
> внешний
> ризонер, запомнить результат в той же базе (м.б. в другом
> графе), и
> закрыть проблему.
>
>
> Да, я думал об организации чего-то вроде nightly reasoning. Хотя
> костыль, конечно... А нет ли (может, в планах) в Virtuoso возможности
> интеграции сторонних ризонеров?

Если ризонер лазит в базу через один из стандартных интерфейсов, то и
проблем никаких. Если страдает производительность из-за размещения базы
данных и логики приложения в разных процессах и соответствующего IPC, то
можно использовать hosted language и, соответственно, in-process client,
он задержек не даёт.

>

[Alexander Sidorov]

Если ризонер лазит в базу через один из стандартных интерфейсов, то и
проблем никаких.

А в список стандартных интерфейсов не входит что-нибудь вроде DIG?

И еще вопрос по ходу. Я правильно понимаю, что в основе Virtuoso RDF-store лежит graph database?

[Ivan Mikhailov]

> Если ризонер лазит в базу через один из стандартных
> интерфейсов, то и
> проблем никаких.
> А в список стандартных интерфейсов не входит что-нибудь вроде DIG?

Вроде нет. Будет запрос в virtuos...@lists.sourceforge.net ---
вполне возможно, что и войдёт.

> И еще вопрос по ходу. Я правильно понимаю, что в основе Virtuoso
> RDF-store лежит graph database?

Таблица квадов одна, c "равноправными" колонками G,S,P,O. Отдельной
операции "создания графа" нет (грузи/вставляй куда хочешь), есть
"оператор-пустышка" CREATE GRAPH, основное назначение которого --- чтобы
"пустышка" DROP GRAPH или ругалась или нет, повторяя логику Jena. Запрос
по всем графам не является проблемой, более того, в дополнение к FROM и
FROM NAMED есть NOT FROM и NOT FROM NAMED, чтобы выбирать из всех
графов, кроме нескольких. Есть graph-level security. Есть именованные
множества графов (graph group), когда приложение думает, что делает
SPARQL SELECT из одного графа, а на самом деле -- из всех графов-членов
списка.

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

Называется ли это graph database? Не знаю :)

[Alexander Sidorov]

> И еще вопрос по ходу. Я правильно понимаю, что в основе Virtuoso
> RDF-store лежит graph database?

Таблица квадов одна, c "равноправными" колонками G,S,P,O. Отдельной
операции "создания графа" нет (грузи/вставляй куда хочешь), есть
"оператор-пустышка" CREATE GRAPH, основное назначение которого --- чтобы
"пустышка" DROP GRAPH или ругалась или нет, повторяя логику Jena. Запрос
по всем графам не является проблемой, более того, в дополнение к FROM и
FROM NAMED есть NOT FROM и NOT FROM NAMED, чтобы выбирать из всех
графов, кроме нескольких. Есть graph-level security. Есть именованные
множества графов (graph group), когда приложение думает, что делает
SPARQL SELECT из одного графа, а на самом деле -- из всех графов-членов
списка.

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

Называется ли это graph database? Не знаю :)

Большое спасибо за подробные ответы :)
А есть ли какие-то общеизвестные алгоритмы/оптимизации, которые бы определяли преимущества графовых RDF-хранилищ перед хранилищами на базе реляционных СУБД? Гугл вдоль и поперек изучил, нашел очень много информации по поводу RDF2RDBMS, но это все немного не то. Складывается впечатление, что эта информация тщательно скрывается вендорами. Но ведь должны быть какие-то базовые теоретические вещи на эту тему...

Всего наилучшего,

Иван Михайлов
OpenLink Software
http://virtuoso.openlinksw.com

--

[Ivan Mikhailov]

> А есть ли какие-то общеизвестные алгоритмы/оптимизации, которые бы
> определяли преимущества графовых RDF-хранилищ перед хранилищами на
> базе реляционных СУБД? Гугл вдоль и поперек изучил, нашел очень много
> информации по поводу RDF2RDBMS, но это все немного не то. Складывается
> впечатление, что эта информация тщательно скрывается вендорами. Но
> ведь должны быть какие-то базовые теоретические вещи на эту тему...

Тут два отдельных вопроса: на диске могут лежать некие сериализации
графов, или некие сетевые модели, или данные в табличном виде --- этот
уровень полностью скрыт от клиента. Клиент видит язык реляционной
алгебры или язык курсоров или map-reduce какой-нибудь --- эта внешняя
сторона не жестко связана с внутренним представлением. Более того, эти
модели хранения в чистом виде в индустриального качества системах не
встречаются, а клиенту может быть предоставлен язык с несколькими
вариантами доступа.

В случае Virtuoso внутри лежат "вроде бы" таблицы, но фактически ---
деревья дельта-модулированных списков (да ещё в некоторых случаях с
битмапами внутри списков), а снаружи --- реляционные SQL и SPARQL, но с
расширениями для транзитивного обхода графов.

[Alexander Sidorov]

Тут два отдельных вопроса: на диске могут лежать некие сериализации
графов, или некие сетевые модели, или данные в табличном виде --- этот
уровень полностью скрыт от клиента. Клиент видит язык реляционной
алгебры или язык курсоров или map-reduce какой-нибудь --- эта внешняя
сторона не жестко связана с внутренним представлением. Более того, эти
модели хранения в чистом виде в индустриального качества системах не
встречаются, а клиенту может быть предоставлен язык с несколькими
вариантами доступа.

Согласен, внутренности современных реляционных СУБД слабо коррелируют с тем, что мы видим снаружи.
Тем не менее абсолютное большинство высокопроизводительных RDF-хранилищ строится на базе не реляционных СУБД (а ведь воспользоваться существующими наработками вроде репликации, транзакций и т. д. так заманчиво...), а графовых СУБД. Особняком здесь стоит Virtuoso. Ведь, насколько я понимаю, на момент принятия решения о "семантизации" Virtuoso в ее состав уже входило реляционное хранилище. Тем не менее, очевидно, было принято решение о написании отдельного RDF-хранилища. Видимо, проводились какие-то сравнения или анализ, который выявил, что специализированное RDF-хранилище будет в разы эффективнее. На интуитивном уровне я понимаю, почему специализированное хранилище шустрее (в конце концов, каждый должен заниматься своим делом), но хотелось бы подкрепить интуицию какими-нибудь более материальными знаниями, алгоритмами и т. д.

[Ivan Mikhailov]

> Согласен, внутренности современных реляционных СУБД слабо коррелируют
> с тем, что мы видим снаружи.
> Тем не менее абсолютное большинство высокопроизводительных
> RDF-хранилищ строится на базе не реляционных СУБД (а ведь
> воспользоваться существующими наработками вроде репликации, транзакций
> и т. д. так заманчиво...), а графовых СУБД. Особняком здесь стоит
> Virtuoso. Ведь, насколько я понимаю, на момент принятия решения о
> "семантизации" Virtuoso в ее состав уже входило реляционное хранилище.
> Тем не менее, очевидно, было принято решение о написании отдельного
> RDF-хранилища. Видимо, проводились какие-то сравнения или анализ,
> который выявил, что специализированное RDF-хранилище будет в разы
> эффективнее. На интуитивном уровне я понимаю, почему
> специализированное хранилище шустрее (в конце концов, каждый должен
> заниматься своим делом), но хотелось бы подкрепить интуицию
> какими-нибудь более материальными знаниями, алгоритмами и т. д.

У нас нет отдельного RDF-хранилища. Мы немного расширили систему типов
SQL и компилятор/рантайм SQL для удобства трансляции из SPARQL в SQL, и
стали пользоваться результатами этой интеграции как для целей RDF, так и
для прочих. В серединке [1] есть краткое описание идеи. Есть несколько
статей подлиннее, но они на английском, кроме того, они тоже скорее про
результат, чем про внутренности.

[1] http://semanticfuture.net/index.php?title=%D0%9F%D1%83%D0%B1%D0%BB%
D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE
%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D0%B4%D0%B0%D0%
BD%D0%BD%D1%8B%D1%85_%D0%B2_%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%
D1%82_%D0%B8_%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF_%D0%BA_%D0%BD%D0%B8%
D0%BC

[Alexander Sidorov]

Похоже, дела обстоят несколько иначе: Replication, Virtual Database, GeoData и Clustered Server (кто бы сомневался :) ) не поддерживаются в OpenSource Edition вообще. Получается, в бесплатной версии нельзя работать с RDF Views (даже с внутренней базой). Очень жаль.

22 декабря 2009 г. 2:34 пользователь Ivan Mikhailov <imikh...@openlinksw.com> написал:

[Ivan Mikhailov]

> Похоже, дела обстоят несколько иначе: Replication, Virtual Database,
> GeoData и Clustered Server (кто бы сомневался :) ) не поддерживаются в
> OpenSource Edition вообще. Получается, в бесплатной версии нельзя
> работать с RDF Views (даже с внутренней базой). Очень жаль.

С внутренней базой RDF Views там всё-таки работают. В остальном верно.
Действительно, Replication и Virtual Database требуют внешних
соединений, что тянет за собой коммерческую версию с лицензией.
Clustered Server --- вообще отдельный на данный момент вариант (один из
двух коммерческих). GeoData пока в процессе резработки, и эта разработка
должна окупаться, в будущем часть этой функциональности, возможно,
окажется в открытой версии, но прямо сейчас бесплатной она может стать
только при появлении большого спонсора.

[Alexander Sidorov]

Наверное, стоит просто попробовать, работает или нет... но пока на это нет времени. Хочется верить, что дела обстоят именно так, как говорите вы. С другой стороны, вот часть переписки со службой поддержки:
Вопрос: "Are Virtual Database, Replication and GeoData not supported at free edition at all or do they have some limitations (for example, connecting to external sources)? As you said for using RDF Views I need to buy license for Virtual Database. And as you also said Virtual Database is not supported at free edition... so is it that correct I can't use RDF Views (for internal relational database) with free edition?"
Ответ: "The Virtual Database, Replication, Clustered Server and Geo data features are not supported in the open source (free) Virtuoso product in an form. A commercial license will be required if any of these features are required ..."

А что значит "Replication, Virtual Database требуют внешних соединений"? Теоретически я же могу сделать репликацию с одной базы внутренней СУБД на другую? Аналогично с Virtual Database.

29 декабря 2009 г. 13:39 пользователь Ivan Mikhailov <imikh...@openlinksw.com> написал:

[Ivan Mikhailov]

On Tue, 2009-12-29 at 14:21 +0600, Alexander Sidorov wrote:
> Наверное, стоит просто попробовать, работает или нет... но пока на это
> нет времени. Хочется верить, что дела обстоят именно так, как говорите
> вы.

Работает, чесслово.

> С другой стороны, вот часть переписки со службой поддержки:
> Вопрос: "Are Virtual Database, Replication and GeoData not supported
> at free edition at all or do they have some limitations (for example,
> connecting to external sources)? As you said for using RDF Views I
> need to buy license for Virtual Database. And as you also said Virtual
> Database is not supported at free edition... so is it that correct I
> can't use RDF Views (for internal relational database) with free
> edition?"
> Ответ: "The Virtual Database, Replication, Clustered Server and Geo
> data features are not supported in the open source (free) Virtuoso
> product in an form. A commercial license will be required if any of
> these features are required ..."

Ответ неполный, отправил в мэйллист разъяснение.

> А что значит "Replication, Virtual Database требуют внешних
> соединений"? Теоретически я же могу сделать репликацию с одной базы
> внутренней СУБД на другую? Аналогично с Virtual Database.

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

[Alexander Sidorov]

У нас нет отдельного RDF-хранилища. Мы немного расширили систему типов
SQL и компилятор/рантайм SQL для удобства трансляции из SPARQL в SQL, и
стали пользоваться результатами этой интеграции как для целей RDF, так и
для прочих. В серединке [1] есть краткое описание идеи. Есть несколько
статей подлиннее, но они на английском, кроме того, они тоже скорее про
результат, чем про внутренности.

[1] http://semanticfuture.net/index.php?title=%D0%9F%D1%83%D0%B1%D0%BB%
D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE
%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D0%B4%D0%B0%D0%
BD%D0%BD%D1%8B%D1%85_%D0%B2_%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%
D1%82_%D0%B8_%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF_%D0%BA_%D0%BD%D0%B8%
D0%BC 

 

Спасибо за статью, было интересно ознакомиться.

Но меня все равно не покидает ощущение, что RDF-хранилище на базе реляционной СУБД - это лишь workaround (как бы хорошо он не был реализован). А цена на "православную graph database" AllegroGraph заставляет поверить, что там реализованы какие-то специфические оптимизации (ну или жадность :) ).
 

Всего наилучшего,

Иван Михайлов
OpenLink Software
http://virtuoso.openlinksw.com

[Ivan Mikhailov]

> Но меня все равно не покидает ощущение, что RDF-хранилище на базе
> реляционной СУБД - это лишь workaround (как бы хорошо он не был
> реализован). А цена на "православную graph database" AllegroGraph
> заставляет поверить, что там реализованы какие-то специфические
> оптимизации (ну или жадность :) ).

С моей ультраконсервативной точки зрения, RDF и SPARQL над ним --- не
более чем удобный синтаксис для подмножества DATALOGа, в котором все
факты имеют фиксированную арность 3, то есть вид P (S, O, G), или даже
арность 2 и вид P_in_G (S, O). Как только SPARQL расширяется до
"наименьшего практически полезного" SPARQL-BI, арность перестаёт играть
какую-либо существенную роль в оптимизации запросов. А коли так ---
нечего удивляться, что задачи реляционной алгебры лучше всего решаются
именно реляционной СУБД :)

Так что достаточно закономерно то, что классическая книга "Логическое
программирование и базы данных" генетически связана с "Semantic Web
Information Management" и с "Машины баз данных и знаний": Letizia Tanca
--- соавтор первой книги и редактор второй, Л.А.Калиниченко ---
переводчик на русский первой и соавтор третьей :)

Чтобы ситуация существенно изменилась, необходимо появление существенно
нового математического аппарата, тогда из него лет за 10-20 образуется
практичный язык программирования.