[Мысля вслух] Теги лучше категорий?^h!

Но ведь теги (= ярлыки) намного удобнее, универсальный и гибче!

да, но они дискретны. А вдруг кто-то наполовину М, а наполовину Жо? Тогда уж лучше описывать непрерывными величинами: 50%М+50%Жо.

Можно так же комплексное исчисление сюда приплести...

Да, дерево совершенно не годится для структурирования информации. Это очевидно каждому кто только обратит внимание на вопрос.

Пока не ушёл, отвечу: нафиг надо. Если «кто-то» наполовину М, а наполовину Жо, то я просто ему дам теги «М» и «Жо».

Главное — удобный поиск. Это конечная цель всего моего сообщения. Если я хочу найти всех друзей с тегом М, то среди них должны быть и среднеполые М-Жо, если только я не скажу «искать М, но не Жо».

Это он типа язвил так.

Если «кто-то» наполовину М, а наполовину Жо, то я просто ему дам теги «М» и «Жо».

Даёшь произвольные и вложенные атрибуты!

И так всем очевидно, что теги лучше.

[troll mode] А потому Nepomuk нужен [/troll mode]

PS. Теги - тоже не верх совершенства.

теги имеют некоторую избыточность по стравнению с деревом. Когда вариантов тегов мало - они удобны. А когда становится больше 100 ? Еще и в голове приходится держать, что *СПб, а не *Питер, *Петербург или *SPb.

А допустим пишем статью себе в бложик про emerge - какие теги давать? *linux, *gentoo, *nix, *emerge, *portage ?

А так есть что-то вроде: /linux/gentoo/emerge

Мало тегов — нет профита, много тегов — замучаешься вводить.

*СПб, а не *Питер, *Петербург или *SPb.

Нужно синонимы. А ещё может быть полезна вложенность (дерево тегов).

Но теги всё равно несовершенны тоже, да.

Ты сначала создай «дерево тэгов» и распредели тэги по категориям. А уж потом поговорим.

А вдруг кто-то наполовину М, а наполовину Жо?

Проблема в том, что категории обычно рисуют деревьями, а не графами.

Вот апельсин должен быть в категории плодов или в категории оранжевых?

Еще и в голове приходится держать, что *СПб, а не *Питер

Это решается понятием синонимов у тэгов.

Мало тегов — нет профита, много тегов — замучаешься вводить.

Решается иерархией тегов. Достаточно вписать «emerge», как оно пропишется в «linux» и «компьютеры».

У тегов есть одна серьёзная проблема. Непереносимость между системами.

Но если бы на всех системах была одна база данных для всех файлов, то при копировании файла можно было бы просто к нему прикладывать текстовый файл с описанием импорта: теги, какая нибудь дополнительная информация.

А если в будущем появится виндовый emerge? :}

а категории не дискретны? в две категории не толкнёшь вот такое, а два тэга назначить - не проблема

> Непереносимость между системами.
как вариант: можно сделать бэкап непомука на одной системе с КДЕ и потом загрузить эту БД на другой системе с КДЕ

Во первых: непомук vs другие индексаторы, во вторых: структура тегов у всех будет своя.

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

Но это уже совсем другая история.

Категории должны описывать параметры выборки, т.е. сами шаблоны, к примеру: тема, время создания, автор. А уже приписывание значений идёт по тегам, к примеру, для катеории авторства: автор1, автор2 и автор3, автор2. Т.е. не сами объекты должны принадлежать категориям, а теги.

Это, на мой взгляд, самый правильный подход к структуризации всего. Это и не даёт разброда в тегах и не допускает однобокой структуризации.

А если в будущем появится виндовый emerge?

Тогда родителя «linux» можно будет убрать. Оставив прямо «компьютеры». Можно также добавить уровень «администрирование».

А, т.е. прописываются только сами теги и они не могут быть одинаковыми в разных категориях? Понятно, пожалуй.

А, т.е. прописываются только сами теги

Да.

и они не могут быть одинаковыми в разных категориях?

В этом примере нет категорий. Есть иерархия тэгов. Но, безусловно, тэг может иметь больше одного родителя.