Облако тэгов, но не простое, а...

Всем привет!
В общем, задача такая: сделать облако тэгов, но только такое, чтобы у нас тем крупнее был шрифт, и тем ближе к центральному слову были тэги, чем чаще они встречаются вместе с центральным тэгом. А не просто, чем чаще они встречаются вообще.
Допустим, клацнули мы по тэгу "PHP", у нас он сразу переехал в центр, и вокруг сгрудились и раздулись MySQL, Apache и HTML, а Basic и Access переехали куда подальше и стали едва различимым шрифтом.. Все потому, что одну статью часто помечают тэгами PHP, MySQL и html, а Basic с php почит не встречается. Ну, т.е. можно и без анимации, конечно. Это мне воображение так рисует картину порсто=).
Короче вот.
Вопрос: кто-нибудь знает, как такое делается, или хотя бы - откуда копать?

Копать отсюда... и до обеда.
Понятно, что без анимации. Иначе это в раздел Flash.

А по существу - сделать можно все. Главное, чтобы цель оправдывала средства. В вашем случае можно написать скрипт, который будет ранжировать теги, в зависимости от частотности. А располагать их он будет не по порядку слева направо, а исходя из общего количества, таким образом, что в результате самый частотный тег будет находиться по центру, а каждый последующий, то слева, то справа от него. Соответственно ранжированию будет уменьшаться и размер шрифта - это уже совсем просто.
В итоге скрипт должен выдать примерно такой код:

Если стоит задача размещения тэга строго по центру в "облаке",я бы разместил все тэги в отдельном блоке фиксированного размера, каждый блок разместил бы в отдельном дочернем блоке. Тогда бы задача позиционирования блоков решалась бы заданием для

думаю, значительно дольше...

Ну, зачем же так сурово?.. Думаю, тут можно и на JS все реализовать. Было бы желание..

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

Главный вопрос - как организовать сам процесс м.. создания этой "семантической сети" (назовем ее пока так). Особенно, меня интересует как сделать под нее таблицу в БД. Если бы можно было сделать таблицу, у которой тэги идут как в заголовках строк, так и в заголовках столбцов - то вроде все понятно. А в перекрестия этих строк просто ставить +1 за каждую встречу тэгов в одной статье. Но. По-моему в MySQL (да и в др. БД) это сделать не реально. А если бы было и реально - то крайне не эффективно: ведь тэгов может быть очень много! А иметь таблицу в 100500 полей..
Конечно, есть вариант сделать колонку tag1, колонку tag2 и колонку intersection, и записывать каждую пару тэгов. но ведь длина такой таблицы будет 100500^2! И что-то мне подсказывает, что должен быть какой-то метод более эффективный, о котором я не знаю..

Если не привязываться ни к какой CMS/имеющейся структуре бд, + стоит задача подсчёта реального тематического "веса" тега в статье, то я бы реализовал "счётчик семантического веса" Так:

1. При создании статьи/страницы/раздела (в зависимости от архитектуры сайта), регулярные выражения процеживают весь контент на предмет вхождения определённых слов (PHP, Basic и проч.) Откуда вам брать рег-выражения думайте сами. Структуру вашег опроекта я не знаю. Они могут формироваться налету исходя из таблицы с тегами, заносимыми в бд из админки/из поля "теги" в форме создания статьи/ формироваться автоматически исходя из определённого количества вхождений слов в статье и комментариях к ней... .
2. Профильтровали контент, выяснили что MSSQL в статье - 20, PHP - 15.
3. Структура таблицы веса тегов:
tag_id | tag_word | tag_weight | tag_link

4. Определяем правило подсчёта веса тега в отдельной статье. Допустим вы решите что вес 4 (что это уж решайте сами, - количество повторений в тексте, либо условный вес в диапазоне от 1 до 10, проставляемый через админку. Я бы, например, ограничил диапазон диапазон значений 100, и просчитвал бы его, например, так - 5 очков за наличие тега в заголовке статьи, 5 очков за повторение тега в заголовке статьи. + по одному очку за каждое повторение тега в тексте статьи.
5. Далее, я бы принял некую пороговую величину веса (10), до достижения которой мы не считаем его вес в статье.
6. Я бы прикинул какого размера у меня будет облако тегов и решил сколько одинаковых тегов разного веса я там могу выводить. Например 3. Но так, как программисты очень любят усложнять себе жизнь, я бы пошёл дальше и сделал бы управление этим параметром $porog через админку модуля "облако тегов".
6. И так, прошлись рег-выражениями по статье. Если какойто вес есть и набрано MSSQL в статье - 20, PHP - 15.
7. То Смотрим все tag_id где tag_word == тегам нашей статьи, отбирая по возрастанию веса тегов статьи (как пример, - от 20 для MSSQL) с лимитом $porog, если у меня отобрались в массиве значения - 19, 25, 61, то я записываю в таблицу tags нашу статью, вместо статьи с весом 19. (в бд будет при таком же отборе 20, 25, 61). А именно, апдейтим запись где вес 19, вставляя наш новый вес, и параметр tag_link, который может быть ссылкой на статью, либо её числовым идентификатором.

P.S. Не буду исправлять в посте. Выборку из таблицы нам надо делать только одного id, у которого наименьший tag_weight. И если вес тега статьи >, то перезаписывать строку в таблице. В таблице всё, включая, при желании, и tag_word можно хранить в числовых полях, как числовые индексы, с которыми субд будет работать очень быстро даже при большом их количестве, хотя сомневаюсь что их перевалит когда-нибудь за 500.

Вот такой вот маленький Яндекс. Надо научится писать лаконично...

(Отредактировано автором: 27 Января, 2011 - 09:04:19)

Bertolomych Для осуществления решения предполагаемой задачи возможно использование последовательных алгоритмов - обеспечивающих определение относительного и абсолютного приоритета целевого тега - с реализацией его последующего отражения в структуру web-страницы в соответствующей позиции В общем случае возможно два принципиальных формата целевого решения базирующихся на алгоритмах P и NP-класса соответственно - в первом случае производится отражение базового тега в заданной позиции и для всех остальных включаемых элементов осуществляется масштабирование и позиционирования - на основе рассчитываемого относиетльного коэффициента - в результата работы такого алгоритма обеспечивается примерное расположение тегов по заданному критерию но с возможными наложениями или напротив пустым пространством Более сложным решение во втором случае является включение оптимизационного алгоритма позволяющего обеспечить модификацию параметров отображение и кернинга шрифта - для наиболее оптимальной визуализации

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

А мне, похоже, надо научиться понятно формулировать задачу.

Потому некоторые уточнения:
1. Задача состоит НЕ в визуализации. Для визуализации есть куча плагинов на том же jquery, ну и вообще это позже такой вопрос встанет.
2. Задача состоит НЕ в том, как определить вес тэга в статье (хотя Zuldek'у - большое спасибо, вероятно его алгоритм мне очень пригодится, когда станет задача расположения результатов в списке, выдаваемом по тэгу). Задача состоит в том, как определить соотношения между двумя тэгами - какие из них часто встречаются вместе (в поле "тэги"), а какие - редко.

Похоже, никто подобными проблемами не занимался, так что изложу свои мысли по этому поводу, может кто подскажет - какие из них больше походят на грамотное решение. =)

Мне пришли в голову два варианта решения.

Первое - самое очевидное. Сделать таблицу tag1_id, tag2_id и frequency (ну, и таблицу кодировок - id, tag_name, разумеется). Ну, и выбирать из нее все записи, где встречается tag1, а при добавлении статьи в БД, соответственно, увеличить на 1 frequency для каждой пары тэгов, записанных в поле "тэги".
Меня напрягает, что размер этой таблицы будет равен количеству записей в квадрате. Конечно, это в пределе. На самом деле, большинство тэгов никогда не встречаются вместе, и соответственно, не образуют записей в таблице.

Второе - немного менее очевидное. Сделать таблицу, в которой хранить связи тэг-статья. Т.е. tag_id, article_id. И тогда по запросу tag1 мы выбираем из этой таблицы, все статьи с этим тэгом, а потом - все тэги, упоминавшиеся в этой статье. Этот вариант мне нравится несколько больше, т.к. при необходимости, его можно расширить на поиск сразу по двум тэгам (опять же - не статей пока, а других тэгов). И вообще как-то он гибче выглядит.
Однако, тут меня напрягают 2 обстоятельства. Во-первых, при большом количестве статей размер таблицы будет примерно (количество статей)*10, что не факт, что меньше, чем (количество тэгов)^2. Во-вторых, я не большой знаток SQL, и не знаю пока, можно ли объединить два вышеописанных действия (SELECT article_id FROM table WHERE tag_id=tag1 и SELECT tag_id FROM table WHERE article_id=[все]article_id's), а если нельзя, то через php это делать будет просто адски долго.

Как-то так..

Bertolomych
imho тегов будет не так много
и их взаимных сочетаний тоже
конечно английский словарь 400 тыщ но технический базовый 3000
а используемые на тематическом сайте - вообще до пара сотен

в облако-же влезет вообще от силы несколько десятков

так что база не упадет

зы и еще, количество записей пар тегов не будет равно числу тэгов в квадрате просто по статистике использования
на примере этого сайта, будет куча тэгов php mysql javaразные и все около этого и в общем-то все
и это на сайте с 9000 хостов ежедневно

(Отредактировано автором: 28 Января, 2011 - 21:19:27)

спасибо, обнадеживающе звучит. =)

Проблема как раз в том, что в моем случае тэгов ожидается очень много. Больно уж широкой тематики сайт (наука, все отрасли), да и на тэги - основная смысловая нагрузка (библиотека, соответственно, ключевые слова - основа поиска по ней).

Но я тоже думаю, что, по крайней мере за первый год, длина таблицы вряд ли вырастит больше чем до 100 000 пересечений. Для таблицы из трех колонок интеджеров вроде не так уж и страшно звучит...

А вообще - с каких длин начинает падать база? =) Вопрос, конечно, не корректный, но все-таки. Так чисто по эмпирическим наблюдениям?

В действительности процесс осуществления корректной визуализации элементов тегов в предполагаемой задачи является важным аспектом поскольку формирование визуального расположения элементов осуществляется в зависимости от рассчитываемой степени их ассоциации - таким образом одним из важных критериев решения целевой задачи является реализация эффективного алгоритма позволяющего по крайней мере осуществлять расчет параметров уровня отношения элементов - при этом при необходимости обеспечения размещения указанных элементов в заданной области оптимизация рассчитанных параметров является NP-задачей

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

Идея великая! Стоит в одном ряду с "Бессмертием" и созданием "AI".

Но, насколько я понял, решается задача попроще.
Чисто механически нужно:
1. С одной стороны - уметь определить список статей, где встречается требуемый набор терминов ("тегов").
2. С другой стороны - уметь вывести список контролируемых терминов, имеющихся в какой-то конкретной статье.
Подзадача №1 уже решена, например, в поисковике Гугл.
Подзадача №2 тоже уже решена. Например, в большинстве текстовых редакторов отлично работает функция "Найти". Загружай в редактор статью - и ищи чего хочешь!

-----
akyl91@mail.ru