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

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


    Представление информации


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

    Каждому файлу соответствует список тегов. Если некоторые файлы помечены тегом «tag1», в корневой папке создается папка /tag1, в нее кладутся ссылки на соответствующие файлы.

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

    Физически файл хранится там, куда указывает первый в списке тег. Таким образом, указав в качестве первого тега «video», мы заставим систему положить файл в папку /video, в которую можно примонтировать диск большого объема.

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

    Для упрощения понимания систематизируем:

    Виды файлов:
    • основной файл — хранится в месте, соответствующем основному тегу
    • ссылка — хранится в месте, соответствующем неосновному тегу
    • обычный файл — хранится внутри папки с иерархической структурой


    Виды папок:
    • тег — папку можно найти, введя ее название
    • иерархическая папка — располагается так же, как основной файл, а ее название уже не является тегом
    • ссылка на тег
    • ссылка на иерархическую папку


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


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

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

    Также можно задать логическое условие из операторов «и», «или», «не» и скобок. Если в поисковой выдаче создать файл, он будет помечен соответствующими тегами; если поиск был по логическому выражению, откроется диалог для выбора нужных тегов. В контекстном меню файла должен быть пункт «Открыть файлы по главному тегу», если мы не находимся в папке соответствующего главного тега. При создании папки создается иерархическая папка. Чтобы вместо папки создать тег, достаточно указать его в списке тегов какого-либо файла.

    При копировании файла извне в зону действия тегов файлу автоматически присваивается тег, соответствующий папке назначения. При копировании папки она по умолчанию добавляется целиком с сохранением иерархической структуры.

    Работа через консоль


    Для нашей системы должна быть реализована полноценная работа через консоль. Очевидно, средствами обычной ФС можно перемещаться по папкам и работать с файлами, соответствующими этим папкам-тегам. Должна нужна возможность написать что-то вроде «cd tag1 and tag2» и перейти в виртуальную папку, содержащую результаты выдачи, посмотреть их список командой ls. Должна быть утилита для просмотра и редактирования списка тегов для файла, команда для перехода в папку главного тега указанного файла, команда для копирования списка тегов одного файла в теги другого.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 11

    • UFO just landed and posted this here
        +2
        Что ж, меня это не сильно пугает, но заставляет сожалеть об отсутствии большого количества свободного времени.
      • UFO just landed and posted this here
          0
          Что вы понимаете под структуризацией? В некоторой мере она здесь присутствует.
          +1
          В свое время думал над схожими идеями и пришел к не менее схожим выводам. Но потом я узнал (точнее, вник — узнать-то про них легко, понять суть идеи сложнее) про онтологии и понял, что теговая ФС, да и вообще любая _сложная_ система на тегах нежизнеспособна. В лучшем случае, теги подходят в качестве интерфейса быстрого поиска (когда резонно полагаем, что разные метки редко встречаются в правильном сочетании, если предмет не имеет отношения к запрашиваемому). Но хранить на этой же основе затруднительно — будет критически не хватать возможности разделить смысловую нагрузку по группам и по смыслам (семантически, цвет и дата изготовления — очень разные показатели, а в виде тегов они будут равнозначны).
            0
            Я бы не сказал, что предложенная система сложна. Ее сложность будет расти в зависимости от использования. Если присвоить каждому файлу один тег, получим сложность, равную сложности обычной ФС. Каждый пользователь сможет выбрать оптимальный уровень сложности, соответствующий его запросам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

              Вы для начала решите зачем оно нужно и кому. Сама по себе теговая fs штука конечно интересная, но в реальности абсолютно бесполезная. Более обобщённый выриант с полнотекстовым поиском выглядит более удобным и жизнеспособным. В общем если хотите посмотреть на живой пример того что вы написали — ковыряйте wds из Vista/7.
                0
                > Лучше разнести физическое местоположение файла и метаинформации.
                Но в предложенной конструкции пользоваться обычным софтом не станет сложнее. Файл будет лежать в /фотки/отпуск/море, там его можно открыть любой программой. А в местах, соответствующих другим проставленным тегам, будут лежать ссылки на этот файл. Хотя может возникнуть путаница из-за множества одинаковых файлов. Может, вы и правы.
                0
                Есть еще такая важная возможность как автоматическое создание тегов на основе содержимого файлов. Иначе будет много лишней ручной работы.

                Only users with full accounts can post comments. Log in, please.