Это хороший способ реализовать функцию поиска в моем приложении Rails, использующем dbpedia и SPARQL? Есть лучший способ это сделать?

Я пытаюсь собрать приложение «поиск фильмов», используя Ruby on Rails 3. Я извлекаю данные из dbpedia, используя SPARQL (RDF и sparql/client). Я хочу, чтобы потенциальный пользователь мог искать фильм, просматривать результаты, а затем щелкать, чтобы просмотреть страницу, которую я создаю для этого фильма и которая содержит дополнительную информацию (как из dbpedia, так и из моей собственной локальной базы данных).

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

У меня есть приложение rails, настроенное на использование MongoDB, поэтому я подумал, что могу использовать его для кэширования некоторых данных DBPedia, чтобы пользователям не нужно было каждый раз ждать запроса. Однако я застрял на лучшем способе реализовать что-то подобное. Моя текущая мысль примерно такая:

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

Когда пользователь выполняет поиск, происходит следующее:

  1. Запустите поисковый запрос в моей локальной базе данных, чтобы получить соответствующие сохраненные фильмы (скорее всего, поиск только по названию и обзору). Если фильм не обновлялся с dbpedia в течение последних X дней, я его не включаю.
  2. Быстро отображайте соответствующие локальные результаты для пользователя и создавайте список этих фильмов.
  3. Пока пользователь просматривает сохраненные результаты, выполняется запрос к dbpedia. Из этого результата запроса я создаю список соответствующих результатов из DBpedia.
  4. Я удаляю из набора результатов запроса dbpedia все фильмы, которые уже находятся в исходном локальном наборе результатов, чтобы пользователь не мог видеть повторяющиеся результаты.
  5. Я отображаю оставшиеся результаты запроса dbpedia под локальными результатами и сохраняю каждый из новых несохраненных результатов в моей локальной базе данных (включая время last_updated и обновление любых существующих локальных элементов по мере необходимости).
  6. Когда пользователь переходит на страницу фильма, основная информация из dbpedia и моя дополнительная информация, которую я храню, уже хранятся локально и могут быть быстро извлечены на странице, но более подробная информация (режиссер, язык, местоположение, ссылки на соответствующие сайты) запрашивается из dbpedia во время загрузки. Я показываю диалоги загрузки и т. д. в разных разделах, пока извлекается новая информация.

Я думал сделать что-то подобное выше, чтобы пользователь мог быстро увидеть несколько результатов, в то время как остальные результаты загружаются из dbpedia, и я сохраняю некоторые вещи, но не безумное количество.

Но я хотел получить некоторую помощь в том, реалистично ли это и является ли это хорошей идеей. Я могу представить, что сначала поиск в моей локальной базе данных может исказить первоначальные результаты пользователя в сторону вещей, которые были найдены ранее, и если их конкретный желаемый фильм (например, если они вставили заголовок) не был найден до того, как он может появиться дальше вниз по списку. Было бы разумнее просто хранить копию соответствующего набора данных (то есть всех фильмов) локально и обновлять ее по мере необходимости? Это было бы слишком, верно?

В любом случае, я был бы очень признателен за некоторые предложения о том, как сделать все как можно более плавным для пользователя, оставаясь при этом в пределах разумного. Заранее спасибо!

Изменить: вот код тестового поискового запроса, который я сейчас использую. Я думал, что делаю его супербазовым для тестирования... но время ожидания много.

query = "
    PREFIX owl: <http://www.w3.org/2002/07/owl#>
    PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    PREFIX dc: <http://purl.org/dc/elements/1.1/>
    PREFIX : <http://dbpedia.org/resource/>
    PREFIX dbpedia2: <http://dbpedia.org/property/>
    PREFIX dbpedia: <http://dbpedia.org/>
    PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
    PREFIX dbo: <http://dbpedia.org/ontology/>

    SELECT ?subject ?label ?abstract ?runtime ?date ?name WHERE {
    {?subject rdf:type <http://dbpedia.org/ontology/Film>}
    UNION
    {?subject rdf:type <http://dbpedia.org/ontology/TelevisionShow>}.
    OPTIONAL {?subject dbo:runtime ?runtime}.
    OPTIONAL {?subject dbo:releaseDate ?date}.
    OPTIONAL {?subject foaf:name ?name}.
    ?subject rdfs:comment ?abstract.
    ?subject rdfs:label ?label.
    FILTER((lang(?abstract) = 'en') && (lang(?label) = 'en') && REGEX(?label, '" + str + "')).

    }
    LIMIT 30
"
 result = {}
 client = SPARQL::Client.new("http://dbpedia.org/sparql")
 result = client.query(query).each_binding  { |name, value| puts value.inspect }
 return result

person Sarah    schedule 30.01.2012    source источник


Ответы (1)


Какой запрос SPARQL вы используете для запроса dbpeid? Должна быть возможность оптимизировать это для повышения производительности. Вы также должны иметь возможность фильтровать, используя URI категорий. Также вы должны иметь возможность использовать прогнозы OFFSET и LIMIT, чтобы уменьшить количество результатов. Если вы используете полнотекстовый поиск, вы также можете рассмотреть возможность использования специфичного для Virtuoso свойства 'bif:contains', так как оно немного быстрее, чем фильтры регулярных выражений, хотя и имеет недостаток, заключающийся в том, что он нестандартен/специфичен для Virtuoso. Кроме того, вы также можете использовать кэширование HTTP для улучшения последующих результатов поиска (неудивительно, что протокол SPARQL работает через HTTP).

Помимо этого, вместо того, чтобы помещать вещи в mongo db, вы можете попробовать просто использовать свой собственный тройной магазин и каждую ночь загружать в него фильмы из dbpedia.

ОТРЕДАКТИРОВАНО на основании запроса

Хорошо, просто методом проб и ошибок следующие шаблоны вызывают большие проблемы:

    ?subject rdfs:comment ?abstract.
    ?subject rdfs:label ?label.
    FILTER((lang(?abstract) = 'en') && (lang(?label) = 'en') && REGEX(?label, '" + str + "')).

Фильтры могут быть медленными, но даже без фильтров время запроса истекает. Я бы больше беспокоился о предложениях OPTIONAL (OPTIONAL может быть медленным). Попробуй без. Возможно, вам потребуется выполнить отдельный запрос для рефератов и этикеток.

person William Greenly    schedule 30.01.2012
comment
Привет, спасибо за ответ! Я добавил некоторый код для примерного запроса, который я использую, просто используя базовое регулярное выражение для проверки строки, но в моем повторном тестировании только сейчас я заметил, что время ожидания МНОГО, когда я пытаюсь запустить его с простой строкой . Я рассмотрю другие ваши предложения сейчас. спасибо! - person Sarah; 31.01.2012