Как сделать теговую ФС удобной для пользования

[Riateche]

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

[Riateche]

Что вы понимаете под структуризацией? В некоторой мере она здесь присутствует.

[safright]

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

[Riateche]

Я бы не сказал, что предложенная система сложна. Ее сложность будет расти в зависимости от использования. Если присвоить каждому файлу один тег, получим сложность, равную сложности обычной ФС. Каждый пользователь сможет выбрать оптимальный уровень сложности, соответствующий его запросам.

Тема, конечно, спорная. Можно привести кучу примеров, почему эта система будет или не будет эффективна. Для того, чтобы она имела право на жизнь, достаточно, чтобы она подходила для работы хотя бы некоторым людям.

[safright]

Я бы не сказал, что предложенная система сложна.

Ну да, она и не является сложной. Проблема, собственно, в том и есть — она не может быть сложной, в принципе.

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

1. уже упоминаемая мной проблема семантической неразберихи. В качестве аналога могу привести сравнение словосочетаний и предложений — словосочетания несут в себе некоторый простейший смысл, но связать воедино _много_ словосочетаний в связанный текст получится с трудом. Предложения же сложней — но и допускают гораздо большую связываемость отдельных фрагментов в нечто цельное;

2. проблема разброса количества значений. В достаточно большой системе (например, теги хабра) количество доминирующих тегов сопоставимо с числом элементов, а «редких» тегов очень много, и, чаще всего, редкий тег принадлежит только одному элементу. Это порождает следующие две проблемы;

3. нивелирование значений — частые теги несут в себе заведомо меньше информации: если первый тег встречается в половине элементов, а второй — только в одном из них, то знание первого дает мало информации, а знание второго — очень много;

4. группировка — думаю, очевидно, что наибольшую пользу дает возможность искать сразу по нескольким тегам. И здесь проблема, знакомая при обычном полнотекстовом поиске — если искать по логическим выражениям, то система поиска становится сложной и, вообще говоря, не теговой (потому что логические выражения — это именно выражения), следовательно, алгебра таких высказываний становиться незамкнутой. Если же использовать простые объединения (все «и» или все «или»), то при малейших ошибках поиск становится нерелеввантным — исчезают нужные значения или они зашумляются посторонними;

5. для сколько-нибудь больших множеств, теги понадобиться группировать в другие теги (порождать пары система-метасистема), и вот при разборе хотя бы таких случаев все очень усложниться — так как перечисленные проблемы потребуют «расширения» на мета-уровень и его взаимодействия с обычной системой тегов (аналогия в папках — найти все файлы из данной папки — это требует рекурсивного обхода. Для тегов проблема растет по экспоненте)

Вообще, моя позиция — нужно не искать доказательства/опровержения какой-то методы, а искать, где та или иная метода лучше всего работает. Теги прекрасно работают в сравнительно однородных и слабосвязанных между собой множествах элементов (тогда недостатки 2,3,4 и, частично, 5 слабо влияют), в то же время для сложной организации со множеством взаимных зависимостей и отношений теги подходят плохо (а ФС — это именно такая сложная штука — достаточно вспомнить ACL и специальные файлы *nix'ов).

[bashor]

Давно вынашиваю подобную идею… Готовой реализации не нашел, а для «самодеятельности» не хватает времени…

Я больше думаю в сторону некой прослойки между ПО и ФС(чтобы для ПО это была обычная ФС).
Таким образом, обычная запись пути "/фото/анапа/2008" соответствует набору тегов «фото», «анапа», «2008». Думаю по умолчанию логический разделитель должен быть «И», а так можно придумать специальные, опциональные(!) конструкции, например "~" = «НЕ» — "/~фото" или так "/~/фото".

Ну есть над чем еще подумать…

[w00dy]

> Наша виртуальная система хранится в своей корневой папке, являющейся обычной папкой в обычной ФС

Натянуть граф на дерево это плохая идея. У вас такая получится в итоге каша, что мама не горюй. Лучше разнести физическое местоположение файла и метаинформации. Тобишь отдельно иерархия, и отдельно какой-нить tags.db где лежит список файлов и ассоциированные теги. С одной стороны пользователь положить фотографии куда-то в /фотки/отпуск/море — дата и потом навесить на часть из них теги, с другой стороны не падает удобство пользования софтом который теги не понимает.

> Для файла можно также указать иерархический тег, например, «programs/python».

программы вообще плохо тегируются. Плюс ко всему их обычно ограниченное кол-во и поэтому можно компактно засунуть в дерево, например «Офис/Word» или «Игры/Тетрис».

> Работа через файловый менеджер

Очень хороший пример — Windows Explorer. Набираете поисковый запрос (или набор тегов) — получаете выборку. Запросы можно сохранить, чтобы далеко не бегать. Плюс возможность задать ограничение или группировку.

> Возможно, в будущем кто-то возьмется за ее реализацию

Вы для начала решите зачем оно нужно и кому. Сама по себе теговая fs штука конечно интересная, но в реальности абсолютно бесполезная. Более обобщённый выриант с полнотекстовым поиском выглядит более удобным и жизнеспособным. В общем если хотите посмотреть на живой пример того что вы написали — ковыряйте wds из Vista/7.

[Riateche]

> Лучше разнести физическое местоположение файла и метаинформации.
Но в предложенной конструкции пользоваться обычным софтом не станет сложнее. Файл будет лежать в /фотки/отпуск/море, там его можно открыть любой программой. А в местах, соответствующих другим проставленным тегам, будут лежать ссылки на этот файл. Хотя может возникнуть путаница из-за множества одинаковых файлов. Может, вы и правы.

[allex]

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