Комментарии 16
На практике приходится работать со множеством уже существующих классификаторов(рубрикаторов), и актуализируется задача синхронизации и определения соответствия, между классификаторами имеющими различную структуру, глубину вложенности а порой даже и различные верхние уровни.
Не решив этих задач — контент для «свежего» классификатора придётся писать самому, что ведёт накладные расходы на содержание дорогого журналистского отдела. Так как это не всегда возможно, то оптимальным будет предоставление контента самими пользователями, но размещаться в «контентной пустыне», чистом рубрикаторе, никто не захочет, поэтому придётся добыть где-то стартовый контент. И даже если вы договоритесь с партнёрами, всё равно встанет задача синхронизации классификаторов.
Также важно понимать, что основная бизнес-модель зарабатывания денег, в таких проектах — это реклама, и весьма вероятно, что придётся подстраиваться под изменение внешних факторов — попросту менять рубрикатор в направлении, которое заранее предсказать нельзя. Поэтому более ценным будет именно умение изменять и синхронизировать существующие классификаторы на ходу (за разумное время) с минимальными потерями знаний в системе.
Идеальный рубрикатор — это утопия, если вы работаете в издательстве журнала лет 7 — вы это и сами понимаете.
Не решив этих задач — контент для «свежего» классификатора придётся писать самому, что ведёт накладные расходы на содержание дорогого журналистского отдела. Так как это не всегда возможно, то оптимальным будет предоставление контента самими пользователями, но размещаться в «контентной пустыне», чистом рубрикаторе, никто не захочет, поэтому придётся добыть где-то стартовый контент. И даже если вы договоритесь с партнёрами, всё равно встанет задача синхронизации классификаторов.
Также важно понимать, что основная бизнес-модель зарабатывания денег, в таких проектах — это реклама, и весьма вероятно, что придётся подстраиваться под изменение внешних факторов — попросту менять рубрикатор в направлении, которое заранее предсказать нельзя. Поэтому более ценным будет именно умение изменять и синхронизировать существующие классификаторы на ходу (за разумное время) с минимальными потерями знаний в системе.
Идеальный рубрикатор — это утопия, если вы работаете в издательстве журнала лет 7 — вы это и сами понимаете.
Я тоже выбрал эту модель для построения рубрикатора.
Единственное отличие — у меня еще существуют поясняющие теги к каждой рубрике (и к вершинам и к листьям)
Единственное отличие — у меня еще существуют поясняющие теги к каждой рубрике (и к вершинам и к листьям)
интересная мысль, но отличаются ли у вас листья от описаний?
Например, лист называется Галантерейные товары, а в тегах у него: Сумки, Кошельки и т.д.
Соответственно в поиске набираем Сумки, получаем лист Галантерейные товары и все компании, попадающие под эту сферу.
Соответственно в поиске набираем Сумки, получаем лист Галантерейные товары и все компании, попадающие под эту сферу.
а подскажите как хранить такие графы в базе? есть ли готовые алгоритмы, типа nestedsets для деревьев?
как список ребер, где в полях будут указаны вершины, которые соединяет ребро
смотря в какой базе, в Cache, например, очень легко хранить графы и деревья — ибо она древовидная БД — никаких алгоритмов не требуется.
В реляционной базе придётся немного извратиться. Вот пример «изврата» habrahabr.ru/blogs/sql/43955/ немного не в тему но всё же.
В реляционной базе придётся немного извратиться. Вот пример «изврата» habrahabr.ru/blogs/sql/43955/ немного не в тему но всё же.
в реляционной см. выше, никакого изврата. Извращаться будет приложение, которое будет подключаться к БД, чтобы забрать данные. Хотя там тоже все просто
В базе всё просто: две таблицы. Сущности и связи.
Причем сущности могут существовать отдельно от связей. Это чтобы можно было отдельно добавлять понятия. Например встретили какой то новый термин — добавали, просто чтобы не забыть про него. А уж потом привязали к соответствующим узлам и отдельно их структурировать. Лист превращается в узел простым добавлением связи. Для удобства показа и обработки там конечно хранится флажок, но это уже мелкая оптимизация.
Причем сущности могут существовать отдельно от связей. Это чтобы можно было отдельно добавлять понятия. Например встретили какой то новый термин — добавали, просто чтобы не забыть про него. А уж потом привязали к соответствующим узлам и отдельно их структурировать. Лист превращается в узел простым добавлением связи. Для удобства показа и обработки там конечно хранится флажок, но это уже мелкая оптимизация.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование графа, как основы для создания рубрикатора