О метках

Если метки будет ставить робот, то такие метки будут не метками, а "индексом", и строить их лучше не в момент написания новости, а в момент индексации, в зависимости от текущего версии алгоритма поиска/индексации.

Обработать/отождествить роботом метки, созданные человеком, можно будет и потом. Конечно, лучше это сделать раньше, чем позже. Однако *проставить* их можно, мне кажется, только в день написания новости (читать старые новости и проставлять им метки, думаю, не захочет никто).

Так что пусть уж лучше метки будут. Потом станет ясно, что с ними делать.

>читать старые новости и проставлять им метки, думаю, не захочет никто

Я абсолютно не против.

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

По твоей аналогии сайт тоже не нужен, есть-же SQL!

> Однако я еще не встречал здесь меток, которые не вствечались бы в тексте, что ставит под сомнение всю эту идею - есть же поиск.

Да, действительно, в норме все ключевые слова должны присутствовать в тексте. Но, не правда ли, ненужность меток отсюда вовсе не следует?

>Но, не правда ли, ненужность меток отсюда вовсе не следует?

Следует.

>По твоей аналогии сайт тоже не нужен, есть-же SQL!

WWW ошибочен.

Ну что ж, давай по шагам :)

Соответственно, стану на минуту занудой.

10 query Поиск нужен для чего?
а) чтобы найти сообщения -- goto 20
б) чтобы найти нужные сообщения -- goto 30
в) поиск не нужен -- exit(1)

20 query Зачем нужен поиск, если можно просто пролистать все сообщения?
а) поиск не нужен -- goto 10
б) потому что задача поиска - фильтровать, и оставить только то, что действительно относится к искомой теме/объекту -- goto 30
в) иное -- exit(1)

30 assert пользователю нужны сообщения по определённой теме, для которой он может выбрать ключевые слова

40 assert слово microsoft может встречаться не только в сообщениях, напрямую связанных с microsoft.
41 Слово KDE может встречаться не только в новостях про KDE, но и в новостях про gnome, qt, libc и даже mplayer.

50 assert если множество A (ключевых слов) лежит в множестве B (всех слов сообщения), то не далеко не всегда A == B

60 assert мы хорошо подумали

70 query Так что, дейстительно ли "следует"?
а) да -- доказательство в студию :)

>WWW ошибочен.

выкинь ошибочную оперу

Пример про КДЕ, как мне кажется, не совсем удачен, ибо есть http://www.linux.org.ru/group.jsp?group=44 А теги удачная штука, если их можно комбинировать для создания выборки по нужной тематике. Например посмотреть все новости по теме KDE+Windows, или Интервью+Linus_Torvalds.

Метки штука хорошая, если правильно реализовать. Сейчас же, насколько я понимаю, все работает в тестовом режиме. Кстати говоря сейчас существуют две метки - Линус и Linus_Torvalds, что явно не есть гуд, так что власть имущим наверное стоит поправить это дело...

Мы все ждем чтобы были видны уже существующие метки при добавлении новости. Скоро все будет :-)

>assert слово microsoft может встречаться не только в сообщениях, напрямую связанных с microsoft

>Слово KDE может встречаться не только в новостях про KDE, но и в новостях про gnome, qt, libc и даже mplayer.

И с большой вероятностью эти слова попадут в "метки".

В html тоже существуют ключевые слова, как-то не ориентируются на них ныне ни пользователи, ни роботы.

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

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

Плюсы этого решения:

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

+2. Не нужно затирать/заменять выставленные ранее метки (хотя, если очень хочется, можно и это сделать). Ошибочно отождествив метки, можно отменить эту операцию назад. В частности, это снижение рисков в принципе позволит администрации допустить к этим операциям несколько больше народу.

+3. Практически полностью снимает проблему выбора языка для проставления меток.

+4. Можно легко реализовать поиск вне зависимости от того, используется какая-то дополнительная индексация или нет.

+5. Этот механизм совместим с другими средствами управления меток, например, каталогом. Также он легко сочетается с тем, чтобы автор видел, какие метки уже есть.

Минус, наверное, один:

-1. у автора может возникнуть неясность, какую метку использовать - linus или линус.

Но и этот минус можно снять, дав автору доступ к информации о текущей группировке меток и, если у автора всё равно остаются проблемы а-ля Буриданов осёл, то также и о том, какая метка в группе сейчас считается основной. То есть можно прямо так и отображать: "линус(linus_torvalis)" - сама метка и корень её группы.

На уровне БД это можно реализовать, например, так:

* новость содержит набор ссылок на метки;

* каждая метка имеет своё строковое представление ("linus") и ссылку на основную метку этой группы.

P.S. (ради чего всё это): И тогда при поиске будут найдены и те, и те сообщения. Можно даже сделать алфавитный указатель, где будут присутствовать обе метки (и обе будут давать одинаковый результат).