Семантическая файловая система

    Предисловие


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

    Недостатки древовидных файловых систем


    В какую папку поместить скачаный фильм: в драмы, избранное, eng movies? Как быстро найти документы, которые я вчера просматривал? Как составить список файлов по каким–либо критериям? Как автоматически рассортировать груду файлов?

    Уверен, каждый сталкивается с похожими проблемами.

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


    Концепция


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

    Базовые принципы:
    • Использование графа, а не дерева. Дерево является частным случаем графа, поэтому последний обеспечивает более гибкое управление связями между файлами – например, каждый узел(файл или папка) может иметь несколько родителей. Это позволяет разместить файл/папку одновременно в нескольких папках.
    • Вычислимые или динамические папки. Содержимое данных папок вычисляется в зависимости от заданных критериев. Например, если в папке Articles создать папку important и наложить на нее условия вроде «расширение pdf, наличие фразы speech recognition», в папке окажутся соответствующие данному условию файлы.
    • Возможность подключения плагинов. Позволит сторонним разработчикам добавить новую функциональность. Например, распознание/категоризация изображений.
    • Использование элементов семантического веба для описания структуры данных. Это позволит системе автоматически разложить серии сериала в нужное место графа либо сгенерировать подходящую структуру.


    Отображение на существующую файловую систему:


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


    UI


    В прототипе в левой части приложения выводился граф, а в правой — список содержимого текущего узла-папки. Есть возможность создания связей между узлами.

    Возможные реализации


    Я начал делать концепт под линукс с помощью FUSE(Python). Пользовательский интерфейс был написан на Java. Однако я слишком приуменьшил объем работы, поэтому разработку пришлось приостановить. В данное время ищу потенциально заинтересованных людей.

    Заметки на будущее


    • Связывание различных источников файлов в один граф – плееров, айжелезок, ноутов, смартфонов. Это обеспечит прозрачную работу с файлами, где бы они не находились.
    • Возможность подключения к системе через сеть.
    • Возможность обмена метаданными с другими пользователями.
    • Создание разных графов для разных пользователей системы.
    • Использование элементов статистики и data mining для подстройски системы под пользователя. Например, это позволит создать вычислимые папки, в которых будут отображаться наиболее часто используемые файлы, самая популярная музыка и видео.


    Выше приведены самые основные элементы системы. Остальное я пока решил оставить за скобками.
    Основной вопрос один: стоит ли продолжать проект?
    Поделиться публикацией

    Комментарии 56

      +2
      Имхо нет.
      Максимум что можно выжать — наподобие Adobe Bridge — семантическое представление информации (т.е. просто индексированный поиск с «умными» фильтрами/папками). Текущая система имхо проста и удобна, а все недостатки надуманны.
      • НЛО прилетело и опубликовало эту надпись здесь
          +1
          Изучите пару видео уроков по Adobe Bridge — удобная штука и решит ваши проблемы (как удачно что вы привели пример именно с фотошопом)
      • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            чтото мне ваша концепция сильно напоминает Microsoft WinFS, которую похоронили на стадии беты, так и не включив в висту
            +7
            Причина кроется в самой сути — каждая папка или файл может иметь только одного родителя, связи между ними являются достаточно жесткими.
            Для большинства файловых систем это утверждение неверно. Так что Вы немного заблуждаетесь в самой этой сути. Раз уж Вы говорите о linux, то та самая ext2/3/4 — как раз граф, а не дерево. И, разумеется, все эти ФС
            позволяет разместить файл/папку одновременно в нескольких папках
            • НЛО прилетело и опубликовало эту надпись здесь
                +1
                Симлинк?
                • НЛО прилетело и опубликовало эту надпись здесь
                    +2
                    Причём тут симлинк? Симлинк не создаёт прямых связей в ФС и нельзя сделать одному файлу двух родителей через симлинк. Может, вы имели ввиду т. н. hardlink?
                      +2
                      Тем не менее через симлинк вы можете открыть файл из любой из двух папок. Зачем нужны жесткие связи в приведенном примере с фильмами — мне непонятно. Я вообще предпочитаю тэги для коллекций фильмов — это же удобнее, чем папки. Имею в виду специфический софт для коллекций, позволяющий тэги.
                        0
                        я думал о тегах. Но у них есть проблема — они обеспечивают «плоское отображение». А мне часто нужна иерархия.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          +2
                          А с моей точки зрения тэги от графов не сильно отличаются… Ну разве что вложенных тэгов не бывает (т.е. тэги не имеют родителей), но зато могут быть категории тэгов (по сути — уже тэги с родителем)… Скажем так: тэги и графы «рядом ходят».
                      +7
                      Уж не знаю, как там в Ubuntu с Ext4, но это всегда можно было сделать так:
                      mv ./file1 ./folder1
                      ln ./folder1/file1 ./folder2/file1
                      Теперь у одного и того же файла два родителя, совершенно равноценных. Или мы о чём-то другом говорим?
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • НЛО прилетело и опубликовало эту надпись здесь
                          –1
                          эээ, ну помоему 2 родителя не у файла, а у файла и у ссылки на него. я конечно не знаю на 100% как там в ext се устроено, но ведь эти вещи все-таки назвали *ссылками*, а не как-то по-другому?
                            +2
                            То есть нужны шашечки, а не ехать?
                              0
                              нет. тогда уж 2 родителя у 2-х ссылок на файл: по 1-му родителю на каждую ссылку. ln без параметров — это хардлинк, полученная ссылка равноправна с исходной.
                                0
                                Итак, повторяем основы. Ссылка — это привязка файла к родительскому каталогу и ничего другого. Файл лежит в каталоге — есть одна ссылка. Делаем вторую ссылку — теперь файл в двух каталогах, эти две ссылки отныне никак не отличаются. Удаляем одну ссылку — файл остаётся существовать (ибо есть одна ссылка), удаляем вторую ссылку — файл пропадает из поля зрения, ибо ссылок на него больше нет. Для каждого файла ведётся учёт количества ссылок, когда их ноль — файл зачищается.
                                  +1
                                  я конечно не знаю на 100% как там в ext се устроено
                                  И, кстати, ext тут непричём — в той же NTFS всё дословно аналогично ;)
                            0
                            Я не совсем правильно выразился. Я хочу создать надстройку над ФС, которая позволит манипулировать файлами, папками и связями на более высоком уровне. Можно написать скрипт на страницу, который будет искать в файле нужное, а можно использовать БД. Примерно такая аналогия.
                              0
                              и граф для пользователя, а не для кишок ФС, про которые конечный пользователь не знает и знать не должен.
                                +1
                                именно это я имел ввиду в своем первом коменте. Согласитесь — новая ФС и новый файловый менеджер это всеже разные вещи. В любом случае, я за файловый менеджер если он будет хотябы реализовывать функционал уже дважды названного мной продукта и при этом быть легковесным и бесплатным.
                              +3
                              Видели nepomuk.kde.org/?
                                0
                                да
                                  +2
                                  И? Чем ваш проект будет отличаться?
                                +2
                                Я считаю, что стоит. Каждый проект, который имеет хоть какие-нибудь шансы стать полезным, стоит реализовывать. Ибо даже самые безумные идеи сегодня могут стать необходимыми завтра. Да и для саморазвития хорошо.
                                  +1
                                  ЕМНИП, попытка создать такую ФС оказалась фатальной для проекта LongHorn :)
                                    0
                                    :)
                                    WinFS мне показалась слишком сложной и запутанной.Но некоторые идеи я решился одолжить.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                    –2
                                    А идея библиотек в Win7 не то же самое?
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                      +3
                                      Автор, поменяйте название на «Еще одно средство индексирования»
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          ну, знаете, я очень люблю самому создавать структуру. на маках из-за этого мне скучно… не могу сделать так как мне нужно
                                            0
                                            > По-моему, это всего лишь удобно для пользователя присвоить какие-то жесткие рамки хранению файлов на своём компе.

                                            +1. имхо, для практического применения пользователем достаточно все файлы хранить в одном каталоге (или их иерархии, например по дате/типу/етц, невидимой конечному пользователю) и оперировать только тэгами.
                                            +3
                                            Не так давно тоже задумался над темой семантических ФС. Если кому-то будет интересно, можете ознакомиться с моим концептом (очень драфт).
                                              0
                                              Я бы к вашему описанию добавил, что SmartTag'и должны быть определены либо в виде скриптов, либо за них должны отвечать какие-то приложения (как системные, так и сторонние), тогда, глядишь, не будет проблем с тем, что приложение прочитает файл «злоумышленника». Ну и при переноске файлов на внешних носителях нужно для SmartTag'ов hash какой-то передавать или что-то в этом роде, а когда файл «возвращается в систему» с внешнего носителя — скрипт или приложение уже должно по структуре определить что можно с этим файлом делать, а что нельзя.
                                                0
                                                Если скрипты, то главная фича — возможность создавать любые свои SmartTag'и. Вот уж тут раздолье для программистов будет.
                                                А имя файла я бы хранил не как Tag, а как атрибут какого-нибудь SmartTag'а «name» (иначе база тэгов очень быстро переполнится сразу после установки ОС, и тормозить все это будет ой-ей).
                                                  0
                                                  В идее записывать алгоритм вычисления атрибутов SmartTag'ов в виде скриптов мне видятся следующие недостатки:
                                                  1) низкая производительность (ведь скрипты может написать любой человек, незнакомый с оптимизацией);
                                                  2) небезопасность;
                                                  3) возможность зацикливания при вычислении атрибутов.

                                                  Вообще-то, все эти же недостатки в какой-то мере присущи и SmartTag'ам, записанным на низкоуровневых языках или машинных инструкциях. Что с этим делать — пока непонятно.

                                                  Имя файла лучше всё же хранить как тег, поскольку так мы сможем построить индекс по именам. Работать должно быстро. Если же это будет вычислимое свойство смарт-тега, то при каждом поиске файла надо будет пробегаться по всем файлам в системе и спрашивать у них атрибут name.
                                                    0
                                                    1) Согласен насчет производительности, но «коли не умеешь, то не лезь». Эта возможность больше для сведущих. Сами по себе скрипты должны быть прекомпилируемыми.
                                                    2) Только с правами администратора их можно править.

                                                    Вообще этим скриптам можно давать предельное время выполнения — если привысил, то, допустим, убивается. Если постоянно превышает, то считается «плохим». Но это уже детали.

                                                    «Если же это будет вычислимое свойство смарт-тега, то при каждом поиске файла надо будет пробегаться по всем файлам в системе и спрашивать у них атрибут name».
                                                    Вовсе необязательно. Если смарт-тег — это, по сути, небольшая утилита, то можно обратиться напрямую к смарт-тегу и запросить у него файлы с указанным атрибутом, внутри себя смарт-тег также обратится к БД, которая сделает быструю выборку.
                                                      0
                                                      Со всем согласен, но не пойму, каким образом ФС найдёт смарт-тег, способный вычислить имена файлов, если сам он является безымянным, и для вычисления своего имени должен обратиться к себе же? =) Или сделать его системным и неизменяемым, чтобы в недрах ФС хранилась ссылка на его дескриптор? Можно, но стоит ли это того? Какой профит?

                                                      К тому же, этот смарт-тег будет хранить и индексировать имена файлов в БД точно так же, как и в случае с жёстко зашитыми именами тегов, так что вряд ли это будет быстрее.

                                                      И последнее: мне не совсем ясно, как будут выглядеть поисковые запросы на уровне консоли? В моём концепте всё прозрачно:
                                                      «select X» — выбрать все файлы с именем «X»;
                                                      «select [Y]» — выбрать файлы с тегом «Y»;
                                                      «select X[Y[Z]]» — выбрать файлы с именем «X», тегом «Y», который помечен тегом «Z».

                                                      Мне кажется, такая запись проста и интуитивно понятна. А как будут выглядеть эти же запросы, если их переписать с использованием вычислимых свойств?
                                                0
                                                В качестве «командной строки» нужна возможность использовать некое подобие SQL-запросов (ну или чего-то близкого), хотя бы как «запасной вариант».
                                                0
                                                но он не является достаточно практичным для простого пользователя. Раскройте эту мысль, пожалуйста.
                                                  0
                                                  Давно думал над чем то в таком духе. Только в том, что я думал, были не папки, а теги.
                                                  К примеру — я открываю файловый менеджер. Выбираю тип файла(музыка, видео, документы, картинки). Потом выбираю нужный тег/ввожу его. Например выбираю «картинки» и «дерево» — показывается куча деревьев. Добавляю тег «человек» — показываются люди с деревьями. И т.д.

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

                                                  Основной недостаток моего подхода — нужно менять все окружение пользователя. Что, конечно, реально, но очень долго.

                                                  В вашем же варианте недостаток в том, что фактически тот же функционал можно реализовать банально симлинками.
                                                    0
                                                    Многие об этом думали. Только пока это не будет удобно реализовано в ОС, причем так, чтобы из любого приложения эти тэги работали, ничего путного не выйдет.
                                                    Зато если такая ОС появится, то это может быть революцией в работе с файлами на компьютере.
                                                    Если Google Chrome OS даст возможность тэггировать данные, которые будут храниться в облаке — это будет первая подобная ОС (если не прав насчет «первости» — поправьте). Хотя я бы предпочел обычную, не «удаленную» ОС.
                                                      +1
                                                      Не обязательно всё и сразу, так точно ничего не выйдет. Вполне можно на основе тегов создавать иерархическую структуру с симлинками — в результате приложения, которые работу с тегами пока что не поддерживают, смогут вполне достойно функционировать.

                                                      Но, да, безусловно — нужна поддержка на уровне ОС. В убунте какой нибудь можно попробовать реализовать, они любят всякие извращения в дистрибутив протаскивать ^^
                                                    +2
                                                    В OS X это уже столет как есть. Называется Smart folders.

                                                      0
                                                      Ну такие же вопросы возникают походу у многих. Вот например различные ссылки по теме.
                                                      [http://habrahabr.ru/blogs/linux/90326/ Правильная организация файлов или наше спасение в наших руках]

                                                      [http://habrahabr.ru/blogs/i_am_insane/68092/ Файловые системы — отстой!]

                                                      [http://tanner.habrahabr.ru/blog/90333/ Как Вы организуете поиск и хранение информации на своём жёстком диске/медиасервере/NAS?]

                                                      [http://rm.pp.ru/info/mhddfs mhddfs: объединение нескольких файловых систем в одну большую виртуальную]

                                                      [http://habrahabr.ru/blogs/development/81352/ Как сделать теговую ФС удобной для пользования]

                                                      [http://amarao-san.livejournal.com/1693391.html tagfs — примерная спецификация]

                                                      [http://demitsuri.habrahabr.ru/blog/40791/ Построение иерархических классификаторов на основе тщательно спроектированной системы тегов]

                                                      [http://habrahabr.ru/blogs/i_am_clever/40679/ Все под рукой или как организовать информацию (Хабр)]

                                                      [http://www.claris-verbis.ru/organizing_information Все под рукой или как организовать информацию]
                                                      +1
                                                      кстати, сдается мне, что то что хочет ТС можно с минимальными усилиями сделать на основе Reiser4. либо, написать плагин к ReiserFS 4.

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                      Самое читаемое