Это хороший способ реализовать функцию поиска в моем приложении Rails, которое использует dbpedia и SPARQL? Есть лучший способ сделать это? - PullRequest
3 голосов
/ 30 января 2012

Я пытаюсь собрать приложение для поиска фильмов с помощью 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, и я храню некоторые вещи, но не безумную сумму.

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

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

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

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

1 Ответ

1 голос
/ 30 января 2012

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

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

ИЗМЕНЕНО на основании запроса

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

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

Фильтры могут быть медленными, но даже без фильтров время ожидания запроса истекает. Я был бы больше обеспокоен ОПЦИОНАЛЬНЫМИ предложениями (ОПЦИОНАЛЬНО может быть медленным). Попробуй это без. Вам может потребоваться выполнить отдельный запрос для тезисов и меток.

...