Проект Tagsistant позиционирует свое творение, tagfs, как следование за общей тенденцией. Интернет шаг за шагом пытаются переводить на семантические рельсы, а файловые системы, считают авторы проекта, закоснели в устарелых принципах — иерархия, директории,
И в принципе, я с ними в чем-то согласен. Представьте, что у вас есть несколько сотен фотографий, одни из которых сделаны в Кёльне, другие сделаны на закате, на третьих изображены девушки, а четвертые сделаны в 2010 году. Теперь вообразите, что вы хотите выполнить следующую операцию: получить список фотографий, которые сделаны на закате в Кёльне с вашей подругой, исключая те, которые были сделаны в 2010 году.
Да, возможно, скажет кто-то, можно ведь создать директории, например, Koeln, sunset, girls, 2010, потом рассовать в них софтлинки на файлы… Как-то так, но разве это предоставит необходимую гибкость и удобство в составлении запросов (хотя бы в решении приведенного выше примера)?
Да, можно попытаться воспользоваться EXIF-тегами. Но камера не указывает в них присутствия девушек на фото и других критериев, ограниченных вашей фантазией. А если речь вообще не о фотографиях, а об отчетах?
Можно попытаться писать своеобразные теги в атрибуты файлов, используя ext4, при помощи setattr\getattr — по крайней мере, я видел такое предложение в вопросе тегирования файлов, не пробовал. Но это тоже половинчатое решение, даже если будет работать.
Реальный пример для затравки, который я могу придумать, исходя из моих потребностей. У меня есть папка с огромным количеством разного картиночного хлама, когда-либо сохраненного в Downloads и позже протегированного (на самом деле, не одна). Я хочу получить из всего этого мусорного полигона список фотографий форумчан-девушек, которые сделаны в Киеве, содержат изображения пива и сделаны раньше 2012 года. Вместе с ними я хочу получить изображения всех админов форума, которые у меня есть:
$ ls ~/tagsistant/store/forum/girls/beer/=Kyiv/time:/year/lt/2012/+/admin/@/
Рассмотрим, что предлагает tagfs.
Самое первое — тегирование файлов, директорий, устройств и даже pipe-ов (!). Второе — отношения между тегами, которые могут быть include, exclude, equivalent и requires. Файлы хранятся в технической директории /archive, теги — в /tags, соответствия файлов тегам — в директории /store. Всего директорий 6:
alias/ archive/ relations/ stats/ store/ tags/
Тегов у файла может быть сколько угодно (в разумных пределах). Синтаксис приписывания тегов файлу выглядит так:
$ ln -s ~/foto1.jpg ~/tagsistant/store/koeln/wife/sunset/@
Мы приписали фотографии набор из трёх не зависящих друг от друга тега: «Кёльн», «жена» и «закат». Теперь эта фотография попадет в выборку по любому из этих тегов, и в любой комбинации из них.
Почему ln -s и зачем «собачка» в конце? Первое — а почему нет? Зачем копировать целый файл, занимая больше места и времени на его копирование, если файл как таковой уже существует, а нам нужно только создать соответствие между ним и тегами?
Второе — символ @ служит маркером, обозначающим окончание ряда тегов. Tagsistant в пути указывает на точку монтирования tagfs, директория store используется для непосредственно связывания файлов с тегами и обращения к ним. Все дальнейшее является рядом тегов, приписываемых файлу. Теперь представьте, что мы добавили еще десять файлов разными наборами тегов: одни содержат только /wife/sunset, другие только /koeln/wife и т.д. Теперь можно делать различные выборки:
$ ls tagsistant/store/koeln/@/
результат: все фотографии, сделанные в Кёльне
$ ls tagsistant/store/koeln/wife/@/
результат: все фотографии жены, сделанные в Кёльне
$ ls tagsistant/store/koeln/wife/-/sunset/@/
результат: то же самое, исключая «закатные» фотографии
Зачем все-таки маркер @? А вот зачем:
fbi (консольный просмотрщик, открывает фото) tagsistant/store/koeln/sunset/@/ (указываем набор тегов и завершаем его) foto2.jpg (указываем конкретный файл из набора фотографий, соответствующего заданным тегам)
Как бы иначе сервис файловой системы разобрался, где тег, а где уже имя файла?..
Операторы
Более сложные выборки можно делать при помощи операторов +, - и фигурных скобок. Примеры:
$ ls ~/tagsistant/store/koeln/+/sunset/@/
Результат: фотографии из Кёльна и фотографии заката; не суперпозиция этих тегов (фотографии, сделанные в Кёльне на закате), а слияние двух различных выборок (фото Кёльна в любое время дня и фото заката, сделанные в абсолютно любом месте).
$ ls ~/tagsistant/store/koeln/-/sunset/-/wife/@/
Аналогично, все фотографии Кёльна, за исключением сделанных на закате. И жену тоже в сторону, нам нужны только фото с рыбалки. :)
(Точно так же работает и оператор слияния выборок +/. Каждый оператор относится только к одному последующему тегу, так что для слияния выборок по трем тегам понадобятся два оператора.)
Для группировки тегов служат фигурные скобки; представьте, что вам нужно составить выборку из трех наборов файлов. Первый набор протегирован одновременно как «starwars» и «image», второй — как «starwars» и «music», третий — как «starwars» и «video». С использованием операторов слияния это можно выразить так:
$ ls ~/tagsistant/store/starwars/image/+/starwars/music/+/starwars/video/@/
Но лучше так:
$ ls ~/tagsistant/store/starwars/{/image/music/video/}/@/
Более сложные варианты использования предполагают и такой пример запроса:
$ ls ~/myfiles/store/{/starwars/startrek/}/{/images/music/video/}/@/
Который выдаст нам выборку всех картинок, музыки и видео, относящихся к двум разных фильмам. Эквивалентный запрос, составленный без группировок, выглядел бы так:
$ ls ~/tagsistant/store/starwars/image/+/starwars/music/+/starwars/video/+/startrek/image/+/startrek/music/+/startrek/video/@/
Сгруппированные теги не могут содержать других группировок (The only thing you can't do with tag groups is nest them). Также обязательно соблюдать парность скобок и не забывать их закрывать.
Перечисление тегов файла и мета-тег ALL
Еще одна, естественно ожидаемая, способность — это вывод списка всех тегов, ассоциированных с файлом. Для его получения нам нужно обратиться командой cat к файлу с суффиксом ".tags". Вот так:
$ cat tagsistant/store/koeln/@/photo1.jpg.tags
koeln
wife
sunset
image
Это в том случае, если мы помним хоть один тег, относящийся к файлу. А если нет, напрочь память отшибло? Нас выручает глобальный мета-тег ALL/. Результат — такой же.
$ cat tagsistant/store/ALL/@/photo1.jpg.tags
Мета-тег ALL выдает абсолютно полный список файлов, содержащихся в tagfs, и может быть полезен, например, для автоматической обработки всех файлов, поскольку рекурсивная обработка папки store не сработает, как в обычных иерархических системах. Либо в случае, как выше — вы помните, что тегировали определенный файл, но не помните ни одного из его тегов. Чтобы посмотреть их список, вы и используете общий мета-тег.
Тройные (композитные) теги
Пожалуй, пора закончить с плоскими тегами и переходить к пространствам имен и тройным тегам (triple tags). Несмотря на то, что и прежние примеры показывали неплохую гибкость использования, у них есть определенные ограничения. Не буду изобретать собственный велосипед и возьму пример из мануала: допустим, я хочу ввести теги с разграничением по годам. Как я могу это реализовать? Создать теги вроде 2000, year_2000 и т.д. по тегу для каждого года. Это захламит директорию тегов и кроме того, могут возникнуть коллизии в названиях тегов.
Второй уровень развития тегов в tagfs, преследуя структуризацию и удобство использования, выражается в композиции тегов из трех элементов, выглядящей как:
Пространство имен — Ключ — Значение
Пространство имен описывает семантическую принадлежность содержащихся пар ключ-значение и может быть достаточно общим, например, для приведенного примера с годами можно применить пространство имен time. Ключи будут выглядеть как year, ну а конкретные цифры будут содержаться в третьем элементе значение.
В реальном использовании в композитном теге есть еще один элемент: оператор. Из списка операторов становится ясной их роль: eq (equals to), inc (includes), gt (greater than), lt (less than). Таким образом полностью схема композитного тега выглядит так:
namespace:/key/operator/value/
Обратите внимание на двоеточие после пространства имен, оно обязательно и служит как раз для определения этого пространства.
Так мы можем расклассицифировать фотографии еще и по годам, месяцам и т.д., не захламляя директорию тегов. Приписывание всем фотографиям из директории с фотографиями из Кёльна тегов, характеризующих их как сделанные в Кёльне в августе 2010 года будет выглядеть так:
$ ln -s ~/Koeln_fotos/*.jpg ~/tagsistant/store/photos/koeln/time:/year/eq/2010/time:/month/eq/August/@/
Когда-нибудь после мы сможем поискать все фотографии, сделанные в 2010 году, и увидеть среди них фотографии из Кёльна.
$ ls ~/tagsistant/store/photos/time:/year/eq/2010/@/
В системе заложены также основы автоматического тегирования исходя из метаданных файла, но потестировать их пока толком не удалось за отсутствием набора файлов с нормальными метаданными (в большинстве случаев это фотографии). В мануале сказано, что можно настраивать регулярные выражения, влияющие на то, какая информация будет добыта из метаданных, редактируя настроечный ini-файл. Было бы удобно, если бы система также добавляла автоматические теги, исходя из расширения файла, например, всем jpeg-png-gif выдавала по тегу image, mp3-flac — music и т.д. Пока неясно, заложен ли такой функционал в проект или нет, возможно, можно написать свой плагин с такой функцией.
Что касается отношений
Их всего четыре: include, exclude, is_equivalent и requires. Стандартный мануал не дает подробного разъяснения по каждому из них. Дается только один пример:
$ mkdir ~/tagsistant/relations/TAG1/includes/TAG2/
После создания такого отношения любой запрос к TAG1 будет выдавать список файлов как с тегом TAG1, так и с TAG2. Пример реального использования — тег images содержит photos. Допустим, во время поездки в Лондон в 2014 году мы сделали несколько фотографий и попутно скачали из интернета какое-то количество картинок. Некоторые из них комиксы с башорга, а некоторые — обои для рабочего стола. В определенный момент мы захотели просмотреть фотографии из Лондона (/London/photos/) за тот период вместе с обоями (/images/), но не тратить время на комиксы (/comics/). Тогда запрос будет выглядеть как-то так:
$ ls ~/tagsistant/store/London/images/time:/year/eq/2014/-/comics/@/
Exclude работает стабильно и очевидно. Множество А включает (include) множество В, множество В исключает С. Теперь, если у нас будет три файла: fileA (тег А), fileB (тег В) и fileC (теги В и С), то запрос к тегу А выдаст fileA и fileB, а fileC будет исключен из поиска. fileC можно будет получить только при прямом обращении к тегу С.
Аналогично действовал бы запрос /store/A/+/B/-/C/@/. Отношения позволяют установить долговременные связи и сократить запросы.
Из источников, отличных от стандартного мануала, становится ясно, что отношение is_equivalent имеет самый очевидный и простой функционал: делает один тег эквивалентным другому в глазах блока рассуждений. Нашлись такие примеры: beatles становился эквивалентным the_beatles, а второй пример на фоне рассуждений о том, что кому-то могут не нравиться теги с использованием нижней черты, вроде my_home, делал my_home эквивалентным my\ home. Зачем — непонятно. (Это всего лишь мое мнение.)
Самое очевидное, что делает отношение requires, это упрятывание одного тега внутрь другого в иерархии файловой системы. То есть, к примеру, если выполнить:
$ mkdir ~/tagsistant/relations/TAG1/requires/TAG2/
$ ln -s ~/somefile.txt ~/tagsistant/store/TAG1/@/
То в дальнейшем мы сможем обращаться к somefile.txt по тегу TAG1, но в списке тегов в директории store мы TAG1 не увидим — он будет запрятан внутрь TAG2/.
$ ls ~/tagsistant/store/
+/ -/ @/ @@/ ALL/ TAG2 {/
$ ls ~/tagsistant/store/TAG2/
+/ -/ @/ @@/ ALL/ TAG1 {/
$ ls ~/tagsistant/store/TAG1/@/
somefile.txt #обращение идет через нужный тег, хотя на этом иерархическом уровне его нет. Впрочем, иерархия тут не очень при делах...
$ cat ~/tagsistant/store/ALL/@/somefile.txt.tags
TAG1 #то есть файл тегирован лишь одним тегом
В случае же, если отношения requires между этими тегами не будет, то TAG1 будет содержаться на верхнем уровне, в директории store/. Пока глубинный онтологический смысл этого отношения до меня не дошел. В скудных описаниях оно толком не расписано.
UPD: в ChangeLog проекта все же нашел упоминание о новом отношении под названием required. Дословно там сказано следующее (в переводе с англ.):
Введено отношение «необходим». Если тег M необходим тегу S, то тег S будет показан лишь в том случае, когда тег M содержится в в последней позиции запроса, например:
store/M/
store/P/Q/+/M/
Но он не будет показан в:
store/P/
store/P/+/Q/
Предназначение этого отношения — организация тегов в иерархическую структуру для предотвращения захламления корневой директории. В какой-то мере оно дополняет функционал пространства имен.
Честно говоря, ясности не внесло. По крайней мере, у меня описанного поведения не наблюдается. Возможно, я просто что-то не понимаю.
Дедупликация и другие палки в колеса
Дедупликация — механизм, предотвращающий использование одинаковыми файлами двух разных inode-ов в файловой системе. Это значит, что приколы с созданием пустого временного файла в качестве флага здесь бы не сработали, но это и не надо — это же вспомогательная специализированная система.
Выглядит это примерно так:
$ touch ~/tagsistant/store/tag1/@/tempfile1
$ touch ~/tagsistant/store/tag2/@/tempfile2
$ touch ~/tagsistant/store/tag2/@/tempfile3
Результатом этих манипуляций будет один лишь tempfile1 с приписанными ему тегами tag1 и tag2. Попытки создания остальных двух файлов натолкнутся на проверку содержания, окажется, что она у них с первым одинаковая (они все одинаково пусты) и теги, приписываемые последней паре, окажутся приписаны первому файлу с прежним именем.
Отключение reasoner'а (блока раздумий)
Завершение ряда тегов в запросе символом @ «включает» вышеупомянутый блок, заставляя его совершать всю логику запроса, использование же двух символов: @@ «выключает» его. Полезно в некоторых случаях, среди которых отдельные операции с файлами и просмотр ассоциированного с тегом множества без участия отношений. Например, если тег А содержит тег В, то по запросу к тегу А система выдаст оба множества. Если же мы отключим ризонер при аналогичном запросе, то получим только множество А:
$ ls ~/tagsistant/store/A/@/
Afile1 Afile2 Bfile1
$ ls ~/tagsistant/store/A/@@/
Afile1 Afile2
Алиасы
Привычную цепочку тегов можно законспирировать в краткий алиас, обозначающийся знаком =. Сопоставленная с алиасом цепочка-запрос будет подставлен as is, так что в результате могут случиться некоторые подвохи. Алиасы хранятся в директории aliases в виде файлов, которые содержат строку ассоциированного запроса. Допустим, файл алиаса с именем behemoth содержит строку behemoth/file:/format/eq/AVI/. В дальнейшем мы подставляем его в более общий запрос:
$ ls ~/tagsistant/store/=behemoth/time:/year/lt/2000/@/
Упомянутый подвох может заключаться в том, что если алиас содержит оператор +/, то вся часть запроса, которая следует после алиаса, будет относится только ко второй его части. Кстати, тоже не совсем понятно, ведь в мануале было сказано, что оператор относится только к одному следующему за ним тегу; возможно, информацию не успели обновить после очередного нововведения.
Слияние тегов
Тоже важная часть, не мог ее не упомянуть. Чтобы слить два тега в один, достаточно просто перенести все содержание директории одного в директорию другого. И удалить первый из них.
$ mv store/merged_tag/@/* store/destination_tag/@/
$ rmdir tags/merged_tag
Не менее важное примечание. Ни в коем случае нельзя удалять не пустую папку в директории /store. Каждая директория каждого тега содержит ссылки на все остальные теги (их директории), так что, удалив папку одного тега, вы снесете весь репозиторий. Все удаления в папке /store могут быть только при завершенном запросе. Запрос становится завершенным, когда содержит маркеры
Чтобы удалить тег, нужно обращаться к директории /tags, а не /store. Все файлы, которым приписан этот тег, останутся в целости, но лишатся соответствующего тега.
Сборка
Tagsistant предназначен для сборки под Linux или BSD, требует библиотеки glib2, fuse, libdbi с плагинами libdbd-sqlite3, libdbd-mysql и libextractor. У меня не десктопный дистрибутив, поэтому я собирал вручную половину зависимостей. При этом Tagsistant собрался только с заголовками sqlite3 (на самом деле, как видно, ему достаточно либо-либо), но выдает какие-то мусорные сообщения. Возможно, как раз потому, что я собрал его без mysql-овских заголовков — после запуска и при работе мусорит в терминал сообщения типа «no tables in statement !». Достаточно перенаправить стандартный вывод в астрал 1>/dev/null, чтобы это прекратилось — на работу это видимым образом не влияет никак.
Конечно, кто-то может высказаться в духе: «зачем этот велосипед, если можно организовать иерархию папок». Я считаю, что никакая иерархия папок не даст такой гибкости и удобства, позволяя задавать совершенно любые запросы, какие только придут в голову. Кроме того, с моей точки зрения велосипедна как раз подобная возня с иерархией, ссылками и тому подобным. EXIF-теги, которые случайно могли кому-то придти в голову из-за примеров с картинками, вряд ли пригодны для тегирования архивов переписок и всего того, что может тегировать Tagsistant. Системе есть куда развиваться, но она уже удобная и стабильная. Обратите на нее внимание.
Комментарии (40)
ababo
03.10.2015 19:47+13Главная проблема не в том, что обычная файловая система не умеет работать с тегами, а в том, что никто не хочет (и не будет) тегировать файлы. Если же появится способ автоматизации тегирования на основе анализа контента, то и сами теги тогда не понадобятся.
janekprostojanek
03.10.2015 21:47+2Кто хочет — тот будет. У меня, например, не вызывает отторжения мысль, что придется ручками что-то пометить, если я буду знать, что потом я благодаря этим действиям очень быстро что-то найду, не перерывая десятки архивов с сотнями картинок «где же та фотография».
А автоматический анализ контента в ближайшем будущем, благодаря разработкам Google, может, и даст некоторую автоматизацию, но никогда не протегирует все именно так, как хотите вы. Если фотография содержит EXIF, то анализатор может узнать, в каком году она сделана; а если нет?janekprostojanek
03.10.2015 21:55А если это не фотография, а zip-архив онлайн-переписки в html-формате, то как его анализировать? Придется опять же ручками критерии создавать, не будет же анализатор за вас угадывать, что и как для вас важно.
Goodkat
04.10.2015 00:50На счёт того, что никто не хочет и не будет тегировать — это примерно как с айтюнсом для организации музыки.
Те, у кого музыка — это свалка папок с файлами, ненавидят айтюнс за то, что он требует проставлять теги. (Те, у кого музыка упорядочена, ненавидят его за всё остальное :)
Когда я обзавёлся айфоном, я постепенно разобрал всю свою свалку файлов проставляя теги для той музыки, которую собирался залить на айфон — по одной-две папки за раз. Заодно выяснил, что процентов 80 всей накопленной музыки я никогда не слушаю, и удалил ненужное.
Так и с тегами для файлов можно поступать — проставлять их по мене надобности.
Впрочем, кроме фотоколлекций я не вижу, где бы теги на уровне файловой системы были особенно полезны. А во всех программах для управления фотоколлекциями теги и так поддерживаются.
С другой стороны, пока Гугл не показал, что теги — это удобно, никто не пользовался тегами для работы с почтой.
OS X и Windows, к примеру, в той или иной степени умеют работать с тегами, но дальше создания пары тестовых тегов я не продвинулся — не придумал пока, для чего они могут мне пригодиться.janekprostojanek
04.10.2015 12:03Музыка.
Старые архивы от учебы (вдруг когда-то кому-то понадобятся старые методички или лабы).
Старые самоучители, за которые я когда-то брался и бросил, и теперь даже не знаю, что они где-то лежат.
Образы с играми, о которых я аналогично забываю, что они вообще есть, но лежат на всякий случай.
Куча всяких разных архивов… вроде и не нужны прямо сейчас, и удалить рука не подымается.
Конечно никто не заставляет тегировать все это. Только то, что важно. А потом я вдруг захочу сыграть в варгейм про вторую мировую, и вместо случайного блуждания по архивам и старым папкам «Games с С», «Games c C-2», «Games from suse» просто набью запрос "/wargame/wwii/".
Киссов послушать опять же удобно без всякого айтюнс: выбрать альбомы позже такого-то года, исключить один из альбомов и несколько песен, которые мне не нравятся, передать список в vlc или mplayer.DrPass
04.10.2015 13:18> Старые архивы от учебы (вдруг когда-то кому-то понадобятся старые методички или лабы).
> Старые самоучители, за которые я когда-то брался и бросил, и теперь даже не знаю, что они где-то лежат.
> Образы с играми, о которых я аналогично забываю, что они вообще есть, но лежат на всякий случай.
Провокационный вопрос: если вдруг ваш винт умрёт и все это внезапно перестанет существовать, это как-то скажется на вашей работе/на вашем отдыхе? Я просто имею точно такую же привычку складывать себе в архивы всякие штуки, которые интересные, полезные, но «сейчас вот нет времени ими заниматься, как-нибудь потом руки дойдут». И там же ещё и старые архивы от учёбы, интересные скорее археологам, т.к. перекочевали в свое время с пятидюймовых дискет на трехдюймовые, и потом прыгая с винта на винт дожили до терабайтной файлопомойки, и старые самоучители, и куча документации, и образы с играми, и много всякого такого. И знаете, сколько раз в жизни оно мне пригождалось? Правильно, ни разу. Было несколько случаев потери архивов. Ну, я в общем-то часто и не мог вспомнить, что именно там пропало. И у моих знакомых такое тоже сплошь и рядом, поэтому полагаю, мой случай не уникальный, а как раз среднестатистический.janekprostojanek
04.10.2015 13:52У меня другой случай — я действительно играю в игры, которые лежат в свалке, время от времени, и действительно могу достать старый самоучитель. А уж старые лабы и методички точно пригодятся, когда знакомые падаваны до второго курса программистского доползут…
Архивы у меня тоже пропадали, было такое, но скорее неважные.
А так.
Винт-то сдохнет, это наверняка. Я должен озаботиться до того, как это случится (явно не завтра) покупкой нового твердотельника.
А если даже он сдохнет, то в случае, если на нем не сгорит контроллер, не упадет на ходу винчестерная головка, а просто станут нечитаемыми какие-то сектора, то с него еще можно будет вытащить данные.
DrPass
04.10.2015 12:17Да и для фотоколлекций оно тоже очень редко требуется. Если человек работает с фотобанками, и ему нужно подбирать тематические фотографии, то ему тегирование будет полезным. Но это достаточно редкий, частный случай. 99.9% пользователей, для которых коллекции фото не являются частью профессиональной деятельности, достаточно даты и названия события. У них просто не возникает потребности «получить список фотографий, которые сделаны на закате в Кёльне с вашей подругой, исключая те, которые были сделаны в 2010 году», а если и возникает раз в год, то ради этого удовольствия они никогда в жизни не станут скрупулёзно проставлять по всем фотографиям в Кёльне тэг «Кёльн», а по всем фотографиям с подругой тэг «подруга».
Музыка уже имеет тэгирование, которое покрывает все потребности — альбом, исполнитель, год и т.д…janekprostojanek
04.10.2015 13:53А я и не говорю, что система ориентирована на 99% «потребителей».
DrPass
04.10.2015 21:29Вы не говорите, но вы же сами написали, что её авторы позиционируют её как нечто, что будет в тренде и соответственно, будет востребовано массовой аудиторией:
> Проект Tagsistant позиционирует свое творение, tagfs, как следование за общей тенденцией. Интернет шаг за шагом пытаются
> переводить на семантические рельсы, а файловые системы, считают авторы проекта, закоснели в устарелых принципах —
> иерархия, директории
Потому я и сказал своё мнение, что мне кажется, массовой аудитории это не будет нужно. Сложность ручного ухода за файловым «хозяйством» в такой системе в большинстве случаев значительно превышает «выхлоп полезности».janekprostojanek
04.10.2015 23:08Ага, вот именно потому так медленно и продвигается semantic web. Просто авторам страниц, а уж тем более промышленным сайтосборщикам лень писать все эти мета-теги. Но все-таки когда-нибудь лень из людей выветрится (или поувольняют тех, кому мета-теги лень писать) и семантический интернет будет. А там и файловые системы подъедут. Нужно только автоматические тегирование доработать, дата-майнинг привлечь, как вот выше писали, чтобы пользователь задавал только тематические критерии, а конкретные теги по этим критериям система майнила и расставляла сама.
Но вот реализация собственно файловой системы хорошо смотрится, как по мне.
Klotos
03.10.2015 20:27+1Спасибо за статью! А сами тэги могут «тэгировать» другие тэги (да, такая вот тавтология :( )? Т.е., к примеру, у меня может быть тэг «Германия», к которому «прикреплены» тэги «Кёльн», «Франкфурт», «Берлин» и т.д., и уже эти тэги второго уровня прикрепляются к фоткам?
janekprostojanek
03.10.2015 21:48Это достигается за счет отношений, в вашем случае include: «Германия» «содержит» названия городов, затем к фотографиям прикрепляются теги городов, но по запросу к тегу «Германия» они все будут выданы.
Плюс, возможно, можно это даже как-то оптимизировать за счет пространства имен.
navar
03.10.2015 21:09+2Вопрос еще в том, как сохранять теги при переносе файлов между разными файловыми системами.
Давно была мысль тегировать фотографии иерархиеческими тегами с сохранением тегов в имени файла. Т.к. ничего готового не нашел, написал прогу phototagger.org.janekprostojanek
03.10.2015 21:52При переносе могут измениться пути, но если пути к файлам не изменятся, если разные ФС будут поддерживать одну абстракцию иерархии. Короче говоря, допустим, вы переносите папку /home/user/Photos с ext4 на какую-нибудь ReiserFS, и в ней эта папка будет располагаться по тому же пути, то ссылки на нее и файлы в ней в tagfs не изменятся. Если я правильно понял вашу мысль. А сами теги-то в sql-формате в файле БД на месте останутся, если даже файлы пропадут.
navar
03.10.2015 22:16+3Не совсем.
Допустим, у меня есть отсортированые по тегам, при помощи Tagsistant, файлы. Мне необходимо кому-то передать некоторые из этих файлов на систему ntfs. Другой человек, как я понимаю, никак не сможет видеть теги, присвоенные файлам.
В программе, что я писал, теги сохраняются в самом имени файла, поэтому, если я их копирую между разными файловыми системами/устройствами, сохраняется возможность поиска файлов по шаблону без установки дополнительного ПО.janekprostojanek
03.10.2015 22:45Видимо, да. Стоит еще учесть, что сейчас система позиционируется как предназначающаяся для Linux&BSD. NTFS таким косвенным образом изначально в пролете.
Возможно, если копировать файлы непосредственно в tagfs, вместо создания ссылок, то потом, сохранив весь репозиторий в образ, можно будет через VM его пользовать… Залить в VM ядро Linux размером мегабайт в 15 плюс библиотеки-зависимости. Но это, конечно, велосипед.
В чем-то ваша идея проще и удобней в использовании. Но наличие базовых отношений включения-исключения и неймспейсов с возможностью «искать по годам раньше указанного» (/time:/year/lt/2015/) — все-таки иногда очень к месту. Зависит от требований и ожиданий, вам вашей утилиты хватает, а мне бы вот было мало. =)
Зато у нее есть плюс, что ее можно под Windows использовать.Goodkat
04.10.2015 00:59+1В Windows поддерживаются теги для файлов. На счёт файловой системы не уверен — может быть только на NTFS.
navar
04.10.2015 01:22Я к тому, что tagfs — отличная идея, но я бы ее развивал в сторону, всё же, сохранения тегов в имени файла, а MySql бы использовал только для индексации и быстрого поиска файлов. Тогда бы мы получили и весь имеющийся сейчас функционал и переносимость файлов между разными носителями. Плюс ко всему я не очень доверяю отдельному хранению тегов и файлов, когда-нибудь что-то может пойти не так и весь труд по присвоению тегов файлам окажется напрасным, ведь даже целостность обыкновенных файловых систем, порой, нарушается.
dtestyk
04.10.2015 01:38сохранения тегов в имени файла
поддерживаюjanekprostojanek
04.10.2015 12:06… Но нет онтологии, даже такой базовой, как здесь.
dtestyk
04.10.2015 15:57не уверен, что сложная онтология тут была бы уместна, а так можно иногда запускать скрипт, переименовывающий алиасы и добавлющий включающие теги;
зачем прятать теги, не понятно, а вот исключения не хватает, это да :(janekprostojanek
05.10.2015 21:28С тегом «необходим» я видимо просто не разобрался с первого раза, а вот включения-исключения очень удобная штука. Более чем. Плюс, если вы заметили, с помощью группировок можно очень коротко делать объемные разветвленные выборки.
Сложной онтологии связей в ТС и нет, по существу. Но та базовая, что есть — исключительно к месту.dtestyk
06.10.2015 01:27теговая система конечно же полезна, но просто сам Tagsistant сейчас не пользуюсь, а на будующее было бы полезно применять ее совместно с распределенным хранилищем типа ipfs(ввиду того, что неудобно работать с хешами)
janekprostojanek
04.10.2015 12:05Это да. Даже сами разработчики предупреждают, что система стабильна, но стоит чему-то произойти в хостовой системе, целостность файла с БД может нарушиться и все насмарку.
MrFrizzy
03.10.2015 22:46Я люблю консоль и консольные утилиты, но не проще ли приспособить под хранение и иерархию тегов какое-нибудь внешнее хранилище, например, графовую бд?
janekprostojanek
04.10.2015 00:46+1Почему консольные? Графические браузеры файлов нормально работают с tagfs, в том-то и половина задумки. :)
Обычные файловые операции интерпретируются Тагсистантом в свои функции, благодаря этому, как отдельно отмечают разработчики, стандартный файловый диалог отлично работает с tagfs.
Внешнее хранилище, БД? Под хранение и иерархию тегов? Так ведь тут они как раз во внешней БД и хранятся.MrFrizzy
04.10.2015 11:32+1Насчет файловых операций — признаю, тут вы правы.
Но как бэкенд сисетма использует sqlite & mysql, если я правильно понимаю зависимости. Мне кажется, что специальная графовая база была бы лучше.
Плюс не снесет ли подключене этой фс алгоритмы встроенным поисковикам: например, в kde поиск любит все кэшировать, читать тэги, писать свои и тому подобное
zim32
04.10.2015 00:50+1А у меня с тегами всегда одна проблема — со временем забываю какими точно тегами я тегировалэ хотя ls и grep по директории с тегами должны частично решить эту проблему.
dtestyk
04.10.2015 01:14+1fbi tagsistant/store/koeln/sunset/@/foto2.jpg
чем-то похоже наdocument.querySelector('jpg.koeln.sunset#foto2')
cat tagsistant/store/koeln/@/photo1.jpg.tags
document.querySelectorAll('jpg.koeln#photo1').classList
ls ~/tagsistant/store/photos/time:/year/eq/2010/@/
document.querySelectorAll('photos[time_year=2010]')
P.S. вроде, уже была статья про tagsistantjanekprostojanek
04.10.2015 01:22Похоже. Ну дык, принцип-то базовый. А файлы пока еще все целиком в вебе не лежат и приходится к ним локальный огород городить...)))
Была, была, но меня она не удовлетворила.
funca
04.10.2015 02:41+2фоточный хлам часто состоит из фоток, собранных из разных источников. с большой вероятностью в них найдутся файлы с «обобщенными» названиями (image.jpg, photo1.jpg и т.п.). как эта штука разруливает случаи, когда имена файлов не уникальны?
допустим, у меня есть несколько коллекций с фотографиями Кёльна, в которых встречаются файлы с одинаковыми названиями.
$ ln -s ~/foo/photo1.jpg ~/tagsistant/store/koeln/sunset/@ $ ln -s ~/bar/photo1.jpg ~/tagsistant/store/koeln/sunrise/@
технически, фотки photo1.jpg в разных директориях разные (на одной запечатлён закат, на другой — рассвет). мне интересно, что будет в этом листинге?
$ ls tagsistant/store/koeln/@/
результат: все фотографии, сделанные в Кёльне
какую из двух фотографий откроет такая команда?
fbi tagsistant/store/koeln/@/photo1.jpg
janekprostojanek
04.10.2015 12:09Насколько я помню, если имена у файлов одинаковые, а содержание разное, то система это распознает и даст файлам префиксы с номером их инода. Она проверяет контрольную сумму содержания, если они у двух файлов совпадают, то она берет только один, а на имя столько внимания не обращает.
sith
04.10.2015 19:52Это не совсем в тему статьи, но встроенное в OS X приложение photos запросто ищет по запросу Koeln, street name, person name, 2010, December без настроек тэгов.
janekprostojanek
04.10.2015 20:04Через EXIF?
sith
06.10.2015 05:24Да. Плюс встроенное распознавание лиц, которые, впрочем, всё равно нужно подтверждать вручную :)
TkWT
иерархия тегов великолепна. вопрос в эти include, exclude можно уложить иерархию зависящую от точки входа?
грубо говоря имеем теги отображенные одноименными папками в корне
париж, фото, год, видео
и в зависимости от точки входа получаем пути типа:
./париж/видео/год/файл1
./фото/год/париж/файл2
и сопутствующий вопрос насколько трудозатратно будет поддерживать такой винегрет в тонусе
janekprostojanek
Этот вопрос я не вполне уловил.
Что подразумевается под точкой входа? Дело в том, что в терминологии системы это означает разные репозитории (их может быть несколько).
Поддерживать? Не знаю, у меня есть несколько архивов с самым разнообразным набором файлов, разбитых по категориям, а сами архивы разбиты по датам. Там есть все, что угодно, но особенно много картинок. Я планирую пройтись по этим архивам и пометить самые важные и интересные фотографии и картинки, а также директории, содержащие что-то интересное. Как помечу — то больше как-то и не особо собираюсь что-то поддерживать, пока не подъедет новый архив. Но уставать в поисках «того самого фото», которое я даже толком не помню в архиве за какую дату лежит — уже не придется.
TkWT
можно ли создать иерархию одинаковых тегов, для одного набора файлов
например имея папку снимков, снятых в разных городах, в разные года с разным форматом
можно ли сгруппировать папки вида /город/год/формат и в то же время иметь возможность просмотреть с деревьями вида /формат/год/город
разнести по разным репозиториям используя ссылки можно и не прибегая к теговой фс
janekprostojanek
От позиции тега в запросе не зависит ничего, так что позиционной иерархии тегов нет.
Нет, имеется в виду репозиторий Tagsistant'а, файловый архив вкупе с внешней БД.
Их может быть несколько, чтобы не переполнять пространство тегов, к примеру репозиторий только для музыки и репозиторий только для фото. Работать с ними можно одновременно, просто точки входа будут разными. В примерах точка входа одна — ~/tagsistant/.