Привет. На хабе уже был материал по Tagsistant, но мне он показался запутанным и неполным.
Эта попытка представить это по-другому представляет собой краткое изложение англоязычного руководства и моих собственных наблюдений.
Проект Tagsistant позиционирует свое творение tagfs как следующее общей тенденции.
Шаг за шагом Интернет пытаются перевести на смысловые рельсы, а файловые системы, считают авторы проекта, закостенели в устаревших принципах – иерархия, каталоги, вот и все.
И в принципе я с ними в чем-то согласен.
Представьте, что у вас есть несколько сотен фотографий, некоторые из которых сделаны в Кельне, другие на закате, третьи девушек, третьи сделаны в 2010 году.
Теперь представьте, что вы хотите выполнить следующую операцию: получить список фотографий, сделанных на закате в Кёльне с вашим другом, за исключением фотографий, сделанных в 2010 году.
Да, возможно, кто-то скажет, можно создавать каталоги, например, Кёльн, закат, девушки, 2010 год, затем поместить в них мягкие ссылки на файлы.
Примерно так, но обеспечит ли это необходимую гибкость и удобство при составлении запросов (хотя бы при решении примера выше)? Да, вы можете попробовать использовать теги EXIF. Но камера не указывает на наличие девушек на фото и другие критерии, ограниченные вашей фантазией.
А если речь идет вообще не о фотографиях, а о отчеты ? Можно попробовать записать уникальные теги к атрибутам файлов с помощью ext4, используя setattr\getattr — по крайней мере, я видел такое предложение в вопросе тегирования файлов, но не пробовал.
Но это также половинчатое решение, даже если оно работает. Настоящий начальный пример, который я могу придумать исходя из своих потребностей.
У меня есть папка с огромным количеством разного ненужного изображения, когда-либо сохраненного в разделе «Загрузки», а затем помеченного тегами (на самом деле их несколько).
Я хочу получить из всей этой помойки список фотографий форумчанок, сделанных в Киеве, содержащих изображения пива и сделанных до 2012 года.
Вместе с ними я хочу получить изображения всех админов форума, которых я иметь:
$ ls ~/tagsistant/store/forum/girls/beer/=Киев/time:/year/lt/2012/+/admin/@/
Давайте посмотрим, что он предлагает теги .
Самое первое — это маркировка файлы, каталоги, устройства и даже каналы (!) .
Второй — это отношения между тегами, которые могут быть «включать», «исключать», «эквивалентными» и «требовать».
Файлы хранятся в технической директории.
/архив , теги - в /теги , сопоставление файлов по тегам - в каталоге /магазин .
Всего существует 6 каталогов: псевдоним/архив/отношения/статистика/магазин/теги/ В файле может быть сколько угодно тегов (в разумных пределах).
Синтаксис присвоения тегов файлу выглядит следующим образом:
$ ln -s ~/foto1.jpg ~/tagsistant/store/koeln/wife/sunset/@Мы присвоили фотографии набор из трех независимых тегов: «Одеколон», «жена» и «закат».
Теперь это фото будет включено в подборку по любому из этих тегов и в любой их комбинации.
Почему пер -с а почему в конце "собака"? Во-первых – почему бы и нет? Зачем копировать весь файл, занимая больше места и времени на его копирование, если сам файл уже существует и нам нужно только создать сопоставление между ним и тегами? Второй – символ @ служит маркером, обозначающим конец серии тегов.
Тегипостоянный в пути указывает на точку монтирования теги , каталог магазин используется для прямого связывания файлов и доступа к ним с помощью тегов.
Все, что следует за этим, представляет собой серию тегов, присвоенных файлу.
А теперь представьте, что мы добавили еще десять файлов с разными наборами тегов: некоторые содержат только /жена/закат , только другие /koeln/жена и т. д. Теперь вы можете делать различные выборки:
$ ls tagsistant/store/koeln/@/ результат: все фотографии сделаны в Кёльне $ ls tagsistant/store/koeln/wife/@/ результат: все фотографии жены сделаны в Кёльне $ ls tagsistant/store/koeln/wife/-/sunset/@/ результат: то же, за исключением «закатных» фотографийЗачем вообще маркер? @ ? Вот почему:
ФБР (консольный просмотрщик, открывает фото) tagsistant/store/koeln/sunset/@/ (укажите набор тегов и заполните его) фото2.jpg (укажите конкретный файл из набора фотографий, соответствующий указанным тегам)Как еще служба файловой системы сможет выяснить, где находится тег, а где имя файла?.
Операторы
Более сложный выбор можно сделать с помощью операторов.+, - и фигурные скобки.
Примеры:
$ ls ~/tagsistant/store/koeln/+/sunset/@/ Результат: фотографии из Кёльна И фотографии заката; не суперпозиция этих тегов (фото, сделанные в Кёльне на закате), а слияние двух разных образцов (фото Кёльна в любое время суток и фото заката, сделанные абсолютно в любом месте).
$ ls ~/tagsistant/store/koeln/-/sunset/-/wife/@/ Аналогично все фотографии Кёльна, за исключением сделанных на закате.(Оператор слияния образцов работает точно так же +/ .А кроме жены нам нужны только фотографии с рыбалки.
:)
Каждый оператор применяется только к одному последующему тегу, поэтому для объединения выборок по трем тегам требуется два оператора.
) Фигурные скобки используются для группировки тегов; Представьте, что вам нужно сделать выборку из трех наборов файлов.
Первый набор помечен одновременно как «звездные войны» и «изображение», второй — как «звездные войны» и «музыка», третий — как «звездные войны» и «видео».
Используя операторы слияния, это можно выразить следующим образом:
$ 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/@/Сгруппированные теги не могут содержать другие группы.
(Единственное, что вы не можете делать с группами тегов, — это вкладывать их) .
Также необходимо следить за тем, чтобы скобки были парными, и не забывать их закрывать.
Перечисление тегов файлов и метатегов ALL
Другая, естественно ожидаемая, возможность — отображать список всех тегов, связанных с файлом.Чтобы получить его, нам нужно связаться с командой кот в файл с суффиксом ".
теги" .
Так:
$ cat tagsistant/store/koeln/@/photo1.jpg.tags Кёльн жена закат изображениеЭто тот случай, если мы помним хотя бы один тег, относящийся к файлу.
А если нет, то у вас совсем потерялась память? Глобальный метатег нам в помощь ВСЕ/ .
Результат тот же.
$ cat tagsistant/store/ALL/@/photo1.jpg.tagsМетатег ALL предоставляет абсолютно полный список файлов, содержащихся в теги , и может быть полезен, например, для автоматической обработки каждый файлы, так как рекурсивная обработка папки хранилища не будет работать как в обычных иерархических системах.
Или в случае, как указано выше — вы помните, что отметили определенный файл, но не помните ни одного его тега.
Чтобы увидеть их список, вы используете общий метатег.
Тройные (составные) теги
Возможно, пришло время остановиться на плоских тегах и перейти к пространствам имен и тройным тегам.Несмотря на то, что предыдущие примеры показали хорошую гибкость использования, они имеют определенные ограничения.
Не буду изобретать велосипед и возьму пример из мануала: допустим, я хочу ввести теги, дифференцированные по годам.
Как я могу это реализовать? Создавайте теги типа 2000 , год_2000 и т. д. по тегам за каждый год. Это приведет к загромождению каталога тегов и, кроме того, могут возникнуть конфликты в именах тегов.
Второй уровень разработки тегов в теги , стремясь к структурированию и простоте использования, выражается в композиции тегов из трех элементов, которая выглядит следующим образом:
Пространство имен – Ключ – ЗначениеПространство имен описывает семантическую идентичность содержащихся пар ключ-значение и может быть достаточно общим, например, для данного примера с годами можно применить пространство имен время .
Ключи будет выглядеть как год , но конкретные числа будут содержаться в третьем элементе значение .
В реальном использовании в составном теге есть еще один элемент: оператор .
Из списка операторов становится понятной их роль: экв.
(равно) Inc. (включает в себя), ГТ (больше чем) лт (меньше, чем).
Таким образом, полная схема составного тега выглядит так:
пространство имен:/ключ/оператор/значение/Обратите внимание на двоеточие после пространства имен; оно необходимо и служит именно для определения этого пространства.
Таким образом, мы также можем классифицировать фотографии по году, месяцу и т. д., не загромождая каталог тегов.
Присвоение всем фотографиям из каталога с фотографиями из Кёльна тегов, характеризующих их как снятых в Кёльне в августе 2010 года, будет выглядеть так:
$ ln -s ~/Koeln_fotos/*.Когда-нибудь позже мы сможем найти все фотографии, сделанные в 2010 году, и увидеть среди них фотографии из Кёльна.jpg ~/tagsistant/store/photos/koeln/time:/year/eq/2010/time:/month/eq/August/@/
$ ls ~/tagsistant/store/photos/time:/year/eq/2010/@/В системе также присутствуют основы автоматической разметки на основе метаданных файлов, но толком их протестировать пока не удалось из-за отсутствия набора файлов с нормальными метаданными (в большинстве случаев это фотографии).
В руководстве говорится, что вы можете настроить регулярные выражения, влияющие на то, какая информация будет извлечена из метаданных, путем редактирования файла конфигурации ini. Было бы удобно, если бы система добавляла еще и автоматические теги по расширению файла, например, всем тегам jpeg-png-gif она выдавала изображение, mp3-flac — музыку и т. д. Пока не ясно, включен ли такой функционал в проект или нет; возможно, вы сможете написать свой собственный плагин с такой функцией.
Что касается отношений
Их всего четыре: включить, исключить, is_equiвалент И требует .Стандартное руководство не дает подробных пояснений по каждому из них.
Приведен только один пример:
$ mkdir ~/tagsistant/relations/TAG1/includes/TAG2/После создания такой связи любой запрос к TAG1 вернет список файлов с тегом ТЭГ1 , так что с ТЭГ2 .
Пример реального использования — тег изображений содержит фото .
Допустим, во время поездки в Лондон в 2014 году мы сделали несколько фотографий и одновременно скачали из Интернета определенное количество снимков.
Некоторые из них — комиксы от башорга, а некоторые — обои на рабочий стол.
В какой-то момент нам захотелось посмотреть фотографии из Лондона.
(/Лондон/фотографии/) за этот период вместе с обоями (/изображений/) , но не тратьте время на комиксы (/комиксы/) .
Тогда запрос будет выглядеть примерно так:
$ ls ~/tagsistant/store/London/images/time:/year/eq/2014/-/comics/@/Исключать работает стабильно и очевидно.
Куча А включает (включить) набор В , куча В исключает С .
Теперь, если у нас есть три файла: файлA (ярлык А ), файлB (ярлык В ) И файлC (теги В И С ), то запрос к тегу А выдам файлA И файлB , А файлC будет исключен из поиска.
файлC можно получить только путем прямого доступа к тегу С .
Запрос будет действовать аналогично /магазин/А/+/Б/-/С/@/ .
Отношения позволяют установить долгосрочные связи и сократить запросы.
Из источников, отличных от стандартного руководства, становится понятно, что соотношение is_equiвалент имеет наиболее очевидную и простую функциональность: делает один тег эквивалентным другому в глазах блока рассуждений.
Были найдены следующие примеры: битлз стали эквивалентом the_beatles, а второй пример - на фоне рассуждений о том, что кому-то могут не нравиться теги с использованием подчеркивания, например мой дом , сделал my_home эквивалентом my\home. Почему не понятно.
(Это только мое мнение.
) Самое очевидное, что делает такое отношение требует , это скрывает один тег внутри другого в иерархии файловой системы.
То есть, например, если вы делаете:
$ mkdir ~/tagsistant/relations/TAG1/requires/TAG2/ $ ln -s ~/somefile.txt ~/tagsistant/store/TAG1/@/Тогда в будущем мы сможем обращаться к somefile.txt по тегу TAG1, но в списке тегов в каталоге магазин TAG1 мы не увидим — он будет спрятан внутри TAG2/.
$ ls ~/tagsistant/store/ +/ -/ @/ @@/ ВСЕ/ТЕГ2 {/ $ ls ~/tagsistant/store/TAG2/ +/ -/ @/ @@/ ВСЕ/ТЕГ1 {/ $ ls ~/tagsistant/store/TAG1/@/ какой-то файл.В случае, если отношения требует между этими тегами не будет, то TAG1 будет содержаться на верхнем уровне, в каталоге магазин/.txt # запрос проходит через необходимый тег, хотя на данном уровне иерархии его не существует. Однако иерархия здесь не очень актуальна.
$ cat ~/tagsistant/store/ALL/@/somefile.txt.tags ТЕГ1# то есть файл помечен только одним тегом
До меня пока не дошел глубокий онтологический смысл этих отношений.
В скудных описаниях он толком не описан.
УПД: В Журнал изменений проект все же нашел упоминание о новых отношениях под названием необходимый.
Там буквально сказано следующее: (перевод с английского) :
Введено «необходимое» соотношение.Честно говоря, никакой ясности это не внесло.Если тег M требуется тегом S, то тег S будет отображаться только в том случае, если тег M содержится в последней позиции запроса, например:
магазин /М/ магазин/P/Q/+/M/Но он не появится в:магазин /П/ магазин/P/+/Q/Целью этой связи является организация тегов в иерархическую структуру, чтобы предотвратить беспорядок в корневом каталоге.В некоторой степени это дополняет функциональность пространства имен.
По крайней мере, я не испытываю описанного поведения.
Возможно, я просто чего-то не понимаю.
Дедупликация и другие палки в колесе
Дедупликация — это механизм, который предотвращает использование одинаковыми файлами двух разных индексных дескрипторов в файловой системе.Это значит, что трюки с созданием пустого временного файла в качестве флага здесь не пройдут, но это и не обязательно — это вспомогательная специализированная система.
Это выглядит примерно так:
$ touch ~/tagsistant/store/tag1/@/tempfile1 $ touch ~/tagsistant/store/tag2/@/tempfile2 $ touch ~/tagsistant/store/tag2/@/tempfile3Результатом этих манипуляций будет только tempfile1 с присвоенными ему тегами tag1 и tag2. Попытки создать оставшиеся два файла столкнутся с проверкой содержимого, окажется, что они имеют то же содержимое, что и первый (все они одинаково пусты) и теги, назначенные последней паре, будут присвоены первому файлу с тем же имя.
Отключение мыслителя (блока мыслей)
Завершение серии тегов в запросе символом @ «включает» вышеуказанный блок, заставляя его выполнять всю логику запроса, используя два символа: @@ «выключает» его.Полезно в некоторых случаях, включая операции с отдельными файлами и просмотр набора, связанного с тегом, без использования связей.
Например, если тег A содержит тег B, то при запросе к тегу A система вернет оба набора.
Если мы отключим резонатор для аналогичного запроса, мы получим только набор A:
$ ls ~/tagsistant/store/A/@/ Файл1 Файл2 BФайл1 $ ls ~/tagsistant/store/A/@@/ Файл1 Файл2
Псевдонимы
Обычную цепочку тегов можно спрятать в короткий псевдоним, обозначаемый знаком = .Цепочка запросов, соответствующая псевдониму, будет заменена как есть, поэтому в результате могут произойти некоторые неприятные вещи.
Псевдонимы хранятся в каталоге псевдонимов в виде файлов, содержащих соответствующую строку запроса.
Допустим, есть файл псевдонима с именем бегемот содержит строку бегемот/файл:/format/eq/AVI/ .
В дальнейшем подставим его в более общий запрос:
$ ls ~/tagsistant/store/=гигант/время:/год/lt/2000/@/Упомянутая загвоздка может заключаться в том, что если псевдоним содержит оператор +/ , то вся часть запроса, следующая за псевдонимом, будет применяться только ко второй его части.
Кстати, тоже не совсем понятно, ведь в инструкции сказано, что оператор применяется только к одному тегу, следующему за ним; Возможно, информация не успела обновиться после очередного нововведения.
Объединение тегов
Тоже немаловажный момент, я не мог его не упомянуть.Чтобы объединить два тега в один, просто перенесите все содержимое каталога одного в каталог другого.
И удалите первый.
$ mv store/merged_tag/@/* store/destination_tag/@/ $ rmdir теги/merged_tagНе менее важное замечание.
Ни при каких обстоятельствах нельзя удалять непустую папку в каталоге /магазин .
Каждая директория каждого тега содержит ссылки на все остальные теги (их каталоги), поэтому если вы удалите папку одного тега, вы удалите весь репозиторий.
Все удаления в папке /магазин может быть только после завершения запроса.
Запрос становится завершенным, когда он содержит маркеры мыслителя: @ или @@ .
В этом случае будут удалены только файлы, которые станут результатом обращения к тегам, указанным в запросе.
Чтобы удалить тег, вам необходимо получить доступ к каталогу /теги , но нет /магазин .
Все файлы, которым присвоен этот тег, останутся нетронутыми, но потеряют соответствующий тег.
Сборка
Tagsistant предназначен для сборки под Linux или BSD, требует наличия библиотек glib2, Fuse, libdbi с плагинами libdbd-sqlite3, libdbd-mysql и libextractor. Десктопного дистрибутива у меня нет, поэтому половину зависимостей я собрал вручную.При этом Tagsistant был собран только с заголовками sqlite3 (на самом деле, как видите, ему достаточно либо-или), но какие-то мусорные сообщения он выдает. Возможно, просто потому, что я скомпилировал его без заголовков mysql - после запуска и во время работы появляются сообщения типа «Нет таблиц в выписке!» .
Достаточно перенаправить стандартный вывод в астрал 1> /dev/ноль чтобы он остановился - на работу это визуально никак не влияет. Конечно, кто-то может высказаться в духе: «зачем этот велосипед, если можно организовать иерархию папок».
Я считаю, что никакая иерархия папок не обеспечит такой гибкости и удобства, позволяя задавать абсолютно любые вопросы, которые приходят в голову.
К тому же, с моей точки зрения, именно такая возня с иерархией, ссылками и тому подобным велосипедно-дружелюбна.
EXIF-теги, которые могли случайно прийти кому-то в голову из-за примеров с картинками, вряд ли подходят для разметки архивов переписки и всего, что умеет тегировать Tagsistant. Системе есть куда развиваться, но она уже удобный и стабильный.
Обратите на нее внимание.
Теги: #tagfs #программирование
-
Звездные Разрушители
19 Oct, 24 -
Обзор Системы Ibm Pure Flex
19 Oct, 24 -
Прыжковое Движение. Впечатление
19 Oct, 24 -
Iphone Как Игровая Консоль
19 Oct, 24 -
Телефона Psp Не Будет
19 Oct, 24
