clihlt
Года 1.5 назад видел в действии программу (уже не припомню название, но если интересно смогу нагуглить) - помощник HR-у.
интересно было бы взглянуть :)

Гата Селовпарсер на > 30 категорий по 6 сайтам, порядка 800 000 объявлений в неделю, за два года эксплуатации всего 2 переделки, обе из - за смены дизайна на сайте).
как-то у вас очень удачно сложилось.
есть другая статистика: >500 сайтов, >1 000 000 объявлений в день, еженедельные правки сканеров/адаптеров. так что не все так радужно)

iv_an_rustatusden,
И кстати сначала выгружайте в RDF, нормализуйте, потом уже складывайте в реляционную СУБД (если это вообще понадобится). Придётся подучиться, зато потом сэкономите кучу времени и качество выхлопа обеспечите поприятнее обычного.
А почему именно в RDF? Есть более легковесные форматы, тот же yaml. Можно вообще без промежуточной выгрузки обойтись, сразу в базу складывать

iv_an_ruhellium,
Я не про RDF/XML, а именно про RDF как модель хранения знаний. Не надо сериализовывать во что-то промежуточное, достаточно, чтобы анализатор сайтов добавлял новые факты в RDF-хранилище и удалял старые. Любым способом, хоть через специализированное API хранилища хоть SPARUL через ODBC/UDBC/IODBC/JDBC... да хоть через веб-сервисы.
Я бы сделал по-простому: данные складываются сразу в mysql-базу, на эту же базу смотрит веб-интерфейс (ну, или делается выгрузка в отдельную базу, адаптированную специально для веба).
Нормализация данных - регекспы, словари, подгружаемые из базы.
Агрегатор - sql + немного скриптовой логики (на чистом sql сделать можно, но будет очень громоздко).

Чем использование rdf-хранилища + специализированных api лучше этой схемы?

iv_an_ru,

iv_an_ru
Я б так сказал, всем, кроме затрат на обучение разработчика.

Одно дело самопальничать словари в какой-то базе неизвестной полноты и актуальности,
другое --- брать готовые из SWEO LOD.

1. вряд ли в SWEO LOD есть полные и актуальные словари на все случаи жизни. Ну или хотя бы данные для более-менее полной модели предметной области по туризму.

2. никто не мешает взять готовые словари, сконвертировать в нужную субд и пользоваться.

Пока преимущества не вижу.

iv_an_ru
Одно дело писать скрипты, другое --- не писать в 99% случаев, просто использовать язык, более подходящий для ad hoc запросов (зато в оставшемся 1% использовать хоть ризонер).

Про какой именно "более подходящий язык" идет речь, с какими именно скриптами он сравнивается, и в контексте каких задач?

iv_an_ru
Одно дело выковыривать данные с нуля написанной самопальной выковыривалкой, другое --- взять нахаляву готовый RDF Sponger и склонировать один из десятков готовых "картриджей"-выковыривателей. Тем более если речь про туризм, когда нужные названия могут запросто оказаться на незнакомом языке, но при этом dbpedia и geonames уже хранят если не русские то уж точно английские эквиваленты. Вы уверены, что у вас не будет трудностей с китаизацией и арабизацией _одновременно_ ?

Давайте по шагам.

1. Сканеры сайтов ("скачать все интересующие страницы с заданного сайта").
В perl, python, php куча готовых решений для этого, со всеми возможными свистелками и финтифлюшками.

Что-то более эффективное, чем уже придуманные решения, изобрести очень трудно, да наверное и незачем. В сложных случаях (картинки, js, антисканеры, капчи) в любом случае с каждым сайтом придется работать индивидуально.

Скриптовые языки здесь более предпочтительны - проще и дешевле найти разработчиков.

2. Адаптеры ("разобрать html-страницу и получить на выходе
структурированные данные").
например из
требуется получить

К сожалению, я не знаю, что есть RDF Sponger'ы и какие у них возможности. Они могут автоматизированно решить эту задачу, без задания человеком правил распознавания для каждого типа страниц? Если нет, то в чем тогда преимущество перед скриптовыми "выдиральщиками" информации?

3. Нормализация данных.

Предметная область у ТС небольшая и сущностей не то чтобы особо много. Верю, что rdf-ориентированные тулзы справятся, но точно так же и скриптовые языки справятся, с помощью регекспов и словарей.

4. Агрегация данных ("определить, что эта группа объектов на самом деле одно и то же и оставить в выходных данных только одну копию объекта")

Собственно, все упирается в задание правил "одинаковости" объектов и производительность обработки.

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

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

Однако, есть мнение, что особая производительность и не потребуется. Во-первых, объем данных неизвестен, во-вторых, даже если он большой, можно разбить данные на независимые блоки и обсчитывать отдельно, на разных железках.

iv_an_ru
"По сумме очков", BBC даже свой собственный архив
каталогизирует в RDF, это при том что там
"поставщик информации" всего один,
всегда "на связи" и всячески помогает архивариусу,
а не гадит. Томас Рейтерс тоже не отстаёт.
А уж эти ребята знают толк в сборе информации.

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

P.S. Было бы интересно услышать, какие компоненты/api вы бы использовали для при реализации подобной системы. Особо интересует выбор rdf-хранилища, api для адаптеров и агрегации информации.

P.P.S. Я правильно понимаю, что rdf-хранилища используются только для обработки/хранения информации, а для выдачи в веб все-таки используются более легковесные базы данных?