1

Тема: Недоступность данных из-за использования SPARQL

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

Есть датасет в формате RDF XML под одну заранее заданную в OWL онтологию. Примерно 3 миллиона триплов, 166Mb чистыми, 9Mb в зипе с сайта. Моя софтинка его грузит и нормально работает.

Есть другие датасеты примерно тех же характеристик ("из одной бочки наливали", но различным образом редактировали, и id у сущностей другие). Доступны только как публичные SPARQL-endpoins.

Следующая версия софтинки сможет искать и доставать для пользователя информацию через SPARQL-запросы. Однако, так я могу только показать что-то пользователю. Чтобы осуществлять проверки и выводы по ISO 15926 мне нужен весь граф. А его я получить не могу.

SELECT ?s ?p ?o WHERE { ?s ?p ?o } (или аналогичный CONSTRUCT) можно использовать только на небольших датасетах, иначе любой приличности сервера дохнут
SELECT ?s ?p ?o WHERE { ?s ?p ?o } OFFSET 0 LIMIT 100 бывает средне, бывает совсем медленно, что видимо связано со спецификой серверного ПО (ту же сотню по regex на именах выдаёт пошустрее), не вариант

Получается подстава: если информация опубликована через SPARQL, значит её уже просрали. Как размер датасетов, так и количество одновременно запрашивающих пользователей будет расти. Скачать целиком не получится, так что остальное (вроде потеряных префиксов) уже мелочь. Полноценно работать можно лишь с файлами. Если они есть.

В то же время, сейчас пишется новая часть ISO 15926-9. По мнению её авторов публикацией reference data libraries (RDL) является введение соответствующего публичного SPARQL-endpoint. "Файлы это не модно". Получается, что информация, необходимая в ежедневной работе онтолога, оказывается доступной только в онлайне (если сервер не перегружен в данный момент) и только для ручного поиска/просмотра, с ней нельзя сделать ничего полезного.

Необходима публикация файлов, и это ещё придётся пробивать в стандарт. Но возникает другой вопрос.

Есть ли хоть один разумный use case для публичных SPARQL-endpoints? В вашей работе были случаи, когда SPARQL на чужом сервере оказывался полезнее вебмордочки для посмотреть и ссылки "скачать" на нём же? Сейчас я склоняюсь к тому, что 15926-9 следует не дополнять, а просто похоронить.

Отредактировано ValKrylov (2011-08-09 03:13:41)

2

Re: Недоступность данных из-за использования SPARQL

Собственно, любой сервер LOD (как lod.openlinksw.com) или его подмножества (как сервисы bio2rdf) является таким use-case-ом. Или services.data.gov/sparql . Мало у кого дома стоит подходящий кластер, чтобы держать весь LOD даже для одного-единственного клиента.

Кроме того, SPARQL 1.1 Graph Store HTTP Protocol как раз предназначен для ввода-вывода целыми графами.

3

Re: Недоступность данных из-за использования SPARQL

iv_an_ru пишет:

Кроме того, SPARQL 1.1 Graph Store HTTP Protocol как раз предназначен для ввода-вывода целыми графами.

Да кто ж его даст, все url для RDL публикуются к SPARQL 1.1 Query. smile Хотя по эффективности должно быть где-то между CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o } и готовыми архивами.

iv_an_ru пишет:

Собственно, любой сервер LOD (как lod.openlinksw.com) или его подмножества (как сервисы bio2rdf) является таким use-case-ом. Или services.data.gov/sparql . Мало у кого дома стоит подходящий кластер, чтобы держать весь LOD даже для одного-единственного клиента.

Однако, даже LOD опасно использовать в таком виде, кроме как "посмотреть глазками для общего развития". Когда в _свою_ систему вкачан датасет, который проверен, подписан, etc, то можно рассчитывать на работоспособность и безопасность системы. Производя миграции между версиями по мере надобности. Если же данные живут своей жизнью, как страницы википедии, результат непредсказуем.

4

Re: Недоступность данных из-за использования SPARQL

В типичном сценарии точка доступа к SPARQL 1.1 Graph Store HTTP Protocol будет описана в VoID-описании сервиса, а описание сервиса X будет доступно на сервисе X как результат выполнения DESCRIBE X.

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

5

Re: Недоступность данных из-за использования SPARQL

А без таких бюджетов ничего и не заведётся.

Т.е. если у POSC Caesar Association или JORD при очередном апдейте датасетов будут ляпы (и практика уже показала, что будут), то могут пострадать справочные и проектные данные компаний, использующих эти датасеты. В фоновом режиме, поначалу незаметно для пользователей.

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

А вот неявные изменения в онтологическом описании росатомовского ВВЭР-ТОИ это уже очень серьёзные проблемы.

6

Re: Недоступность данных из-за использования SPARQL

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

Тем не менее по мере накопления опыта DaaS (Data as a Service) потихонечку идёт в массы. Есть ведь и добротные датасеты. (Собственно, если данные --- барахло, то никто и не будет платить столько-то миллицентов за триплет).

Кроме того, иногда удалённый SPARQL как раз используется сообществом, чтобы так и сяк валидировать текущее "живое" состояние датасета на сайте его основного разработчика.