Как стать автором
Обновить

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

иерархия тегов великолепна. вопрос в эти include, exclude можно уложить иерархию зависящую от точки входа?
грубо говоря имеем теги отображенные одноименными папками в корне
париж, фото, год, видео
и в зависимости от точки входа получаем пути типа:
./париж/видео/год/файл1
./фото/год/париж/файл2
и сопутствующий вопрос насколько трудозатратно будет поддерживать такой винегрет в тонусе
Этот вопрос я не вполне уловил.
Что подразумевается под точкой входа? Дело в том, что в терминологии системы это означает разные репозитории (их может быть несколько).

Поддерживать? Не знаю, у меня есть несколько архивов с самым разнообразным набором файлов, разбитых по категориям, а сами архивы разбиты по датам. Там есть все, что угодно, но особенно много картинок. Я планирую пройтись по этим архивам и пометить самые важные и интересные фотографии и картинки, а также директории, содержащие что-то интересное. Как помечу — то больше как-то и не особо собираюсь что-то поддерживать, пока не подъедет новый архив. Но уставать в поисках «того самого фото», которое я даже толком не помню в архиве за какую дату лежит — уже не придется.
можно ли создать иерархию одинаковых тегов, для одного набора файлов
например имея папку снимков, снятых в разных городах, в разные года с разным форматом
можно ли сгруппировать папки вида /город/год/формат и в то же время иметь возможность просмотреть с деревьями вида /формат/год/город
разнести по разным репозиториям используя ссылки можно и не прибегая к теговой фс

От позиции тега в запросе не зависит ничего, так что позиционной иерархии тегов нет.
Нет, имеется в виду репозиторий Tagsistant'а, файловый архив вкупе с внешней БД.
Их может быть несколько, чтобы не переполнять пространство тегов, к примеру репозиторий только для музыки и репозиторий только для фото. Работать с ними можно одновременно, просто точки входа будут разными. В примерах точка входа одна — ~/tagsistant/.
Главная проблема не в том, что обычная файловая система не умеет работать с тегами, а в том, что никто не хочет (и не будет) тегировать файлы. Если же появится способ автоматизации тегирования на основе анализа контента, то и сами теги тогда не понадобятся.
Кто хочет — тот будет. У меня, например, не вызывает отторжения мысль, что придется ручками что-то пометить, если я буду знать, что потом я благодаря этим действиям очень быстро что-то найду, не перерывая десятки архивов с сотнями картинок «где же та фотография».
А автоматический анализ контента в ближайшем будущем, благодаря разработкам Google, может, и даст некоторую автоматизацию, но никогда не протегирует все именно так, как хотите вы. Если фотография содержит EXIF, то анализатор может узнать, в каком году она сделана; а если нет?
А если это не фотография, а zip-архив онлайн-переписки в html-формате, то как его анализировать? Придется опять же ручками критерии создавать, не будет же анализатор за вас угадывать, что и как для вас важно.
На счёт того, что никто не хочет и не будет тегировать — это примерно как с айтюнсом для организации музыки.
Те, у кого музыка — это свалка папок с файлами, ненавидят айтюнс за то, что он требует проставлять теги. (Те, у кого музыка упорядочена, ненавидят его за всё остальное :)
Когда я обзавёлся айфоном, я постепенно разобрал всю свою свалку файлов проставляя теги для той музыки, которую собирался залить на айфон — по одной-две папки за раз. Заодно выяснил, что процентов 80 всей накопленной музыки я никогда не слушаю, и удалил ненужное.

Так и с тегами для файлов можно поступать — проставлять их по мене надобности.
Впрочем, кроме фотоколлекций я не вижу, где бы теги на уровне файловой системы были особенно полезны. А во всех программах для управления фотоколлекциями теги и так поддерживаются.
С другой стороны, пока Гугл не показал, что теги — это удобно, никто не пользовался тегами для работы с почтой.
OS X и Windows, к примеру, в той или иной степени умеют работать с тегами, но дальше создания пары тестовых тегов я не продвинулся — не придумал пока, для чего они могут мне пригодиться.
Музыка.
Старые архивы от учебы (вдруг когда-то кому-то понадобятся старые методички или лабы).
Старые самоучители, за которые я когда-то брался и бросил, и теперь даже не знаю, что они где-то лежат.
Образы с играми, о которых я аналогично забываю, что они вообще есть, но лежат на всякий случай.
Куча всяких разных архивов… вроде и не нужны прямо сейчас, и удалить рука не подымается.

Конечно никто не заставляет тегировать все это. Только то, что важно. А потом я вдруг захочу сыграть в варгейм про вторую мировую, и вместо случайного блуждания по архивам и старым папкам «Games с С», «Games c C-2», «Games from suse» просто набью запрос "/wargame/wwii/".
Киссов послушать опять же удобно без всякого айтюнс: выбрать альбомы позже такого-то года, исключить один из альбомов и несколько песен, которые мне не нравятся, передать список в vlc или mplayer.
> Старые архивы от учебы (вдруг когда-то кому-то понадобятся старые методички или лабы).
> Старые самоучители, за которые я когда-то брался и бросил, и теперь даже не знаю, что они где-то лежат.
> Образы с играми, о которых я аналогично забываю, что они вообще есть, но лежат на всякий случай.
Провокационный вопрос: если вдруг ваш винт умрёт и все это внезапно перестанет существовать, это как-то скажется на вашей работе/на вашем отдыхе? Я просто имею точно такую же привычку складывать себе в архивы всякие штуки, которые интересные, полезные, но «сейчас вот нет времени ими заниматься, как-нибудь потом руки дойдут». И там же ещё и старые архивы от учёбы, интересные скорее археологам, т.к. перекочевали в свое время с пятидюймовых дискет на трехдюймовые, и потом прыгая с винта на винт дожили до терабайтной файлопомойки, и старые самоучители, и куча документации, и образы с играми, и много всякого такого. И знаете, сколько раз в жизни оно мне пригождалось? Правильно, ни разу. Было несколько случаев потери архивов. Ну, я в общем-то часто и не мог вспомнить, что именно там пропало. И у моих знакомых такое тоже сплошь и рядом, поэтому полагаю, мой случай не уникальный, а как раз среднестатистический.
У меня другой случай — я действительно играю в игры, которые лежат в свалке, время от времени, и действительно могу достать старый самоучитель. А уж старые лабы и методички точно пригодятся, когда знакомые падаваны до второго курса программистского доползут…
Архивы у меня тоже пропадали, было такое, но скорее неважные.
А так.
Винт-то сдохнет, это наверняка. Я должен озаботиться до того, как это случится (явно не завтра) покупкой нового твердотельника.
А если даже он сдохнет, то в случае, если на нем не сгорит контроллер, не упадет на ходу винчестерная головка, а просто станут нечитаемыми какие-то сектора, то с него еще можно будет вытащить данные.
Да и для фотоколлекций оно тоже очень редко требуется. Если человек работает с фотобанками, и ему нужно подбирать тематические фотографии, то ему тегирование будет полезным. Но это достаточно редкий, частный случай. 99.9% пользователей, для которых коллекции фото не являются частью профессиональной деятельности, достаточно даты и названия события. У них просто не возникает потребности «получить список фотографий, которые сделаны на закате в Кёльне с вашей подругой, исключая те, которые были сделаны в 2010 году», а если и возникает раз в год, то ради этого удовольствия они никогда в жизни не станут скрупулёзно проставлять по всем фотографиям в Кёльне тэг «Кёльн», а по всем фотографиям с подругой тэг «подруга».
Музыка уже имеет тэгирование, которое покрывает все потребности — альбом, исполнитель, год и т.д…
А я и не говорю, что система ориентирована на 99% «потребителей».
Вы не говорите, но вы же сами написали, что её авторы позиционируют её как нечто, что будет в тренде и соответственно, будет востребовано массовой аудиторией:
> Проект Tagsistant позиционирует свое творение, tagfs, как следование за общей тенденцией. Интернет шаг за шагом пытаются
> переводить на семантические рельсы, а файловые системы, считают авторы проекта, закоснели в устарелых принципах —
> иерархия, директории
Потому я и сказал своё мнение, что мне кажется, массовой аудитории это не будет нужно. Сложность ручного ухода за файловым «хозяйством» в такой системе в большинстве случаев значительно превышает «выхлоп полезности».
Ага, вот именно потому так медленно и продвигается semantic web. Просто авторам страниц, а уж тем более промышленным сайтосборщикам лень писать все эти мета-теги. Но все-таки когда-нибудь лень из людей выветрится (или поувольняют тех, кому мета-теги лень писать) и семантический интернет будет. А там и файловые системы подъедут. Нужно только автоматические тегирование доработать, дата-майнинг привлечь, как вот выше писали, чтобы пользователь задавал только тематические критерии, а конкретные теги по этим критериям система майнила и расставляла сама.
Но вот реализация собственно файловой системы хорошо смотрится, как по мне.
Спасибо за статью! А сами тэги могут «тэгировать» другие тэги (да, такая вот тавтология :( )? Т.е., к примеру, у меня может быть тэг «Германия», к которому «прикреплены» тэги «Кёльн», «Франкфурт», «Берлин» и т.д., и уже эти тэги второго уровня прикрепляются к фоткам?
Это достигается за счет отношений, в вашем случае include: «Германия» «содержит» названия городов, затем к фотографиям прикрепляются теги городов, но по запросу к тегу «Германия» они все будут выданы.

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

Давно была мысль тегировать фотографии иерархиеческими тегами с сохранением тегов в имени файла. Т.к. ничего готового не нашел, написал прогу phototagger.org.
При переносе могут измениться пути, но если пути к файлам не изменятся, если разные ФС будут поддерживать одну абстракцию иерархии. Короче говоря, допустим, вы переносите папку /home/user/Photos с ext4 на какую-нибудь ReiserFS, и в ней эта папка будет располагаться по тому же пути, то ссылки на нее и файлы в ней в tagfs не изменятся. Если я правильно понял вашу мысль. А сами теги-то в sql-формате в файле БД на месте останутся, если даже файлы пропадут.
Не совсем.
Допустим, у меня есть отсортированые по тегам, при помощи Tagsistant, файлы. Мне необходимо кому-то передать некоторые из этих файлов на систему ntfs. Другой человек, как я понимаю, никак не сможет видеть теги, присвоенные файлам.
В программе, что я писал, теги сохраняются в самом имени файла, поэтому, если я их копирую между разными файловыми системами/устройствами, сохраняется возможность поиска файлов по шаблону без установки дополнительного ПО.
Видимо, да. Стоит еще учесть, что сейчас система позиционируется как предназначающаяся для Linux&BSD. NTFS таким косвенным образом изначально в пролете.
Возможно, если копировать файлы непосредственно в tagfs, вместо создания ссылок, то потом, сохранив весь репозиторий в образ, можно будет через VM его пользовать… Залить в VM ядро Linux размером мегабайт в 15 плюс библиотеки-зависимости. Но это, конечно, велосипед.

В чем-то ваша идея проще и удобней в использовании. Но наличие базовых отношений включения-исключения и неймспейсов с возможностью «искать по годам раньше указанного» (/time:/year/lt/2015/) — все-таки иногда очень к месту. Зависит от требований и ожиданий, вам вашей утилиты хватает, а мне бы вот было мало. =)
Зато у нее есть плюс, что ее можно под Windows использовать.
В Windows поддерживаются теги для файлов. На счёт файловой системы не уверен — может быть только на NTFS.
Я к тому, что tagfs — отличная идея, но я бы ее развивал в сторону, всё же, сохранения тегов в имени файла, а MySql бы использовал только для индексации и быстрого поиска файлов. Тогда бы мы получили и весь имеющийся сейчас функционал и переносимость файлов между разными носителями. Плюс ко всему я не очень доверяю отдельному хранению тегов и файлов, когда-нибудь что-то может пойти не так и весь труд по присвоению тегов файлам окажется напрасным, ведь даже целостность обыкновенных файловых систем, порой, нарушается.
сохранения тегов в имени файла
поддерживаю
… Но нет онтологии, даже такой базовой, как здесь.
не уверен, что сложная онтология тут была бы уместна, а так можно иногда запускать скрипт, переименовывающий алиасы и добавлющий включающие теги;
зачем прятать теги, не понятно, а вот исключения не хватает, это да :(
С тегом «необходим» я видимо просто не разобрался с первого раза, а вот включения-исключения очень удобная штука. Более чем. Плюс, если вы заметили, с помощью группировок можно очень коротко делать объемные разветвленные выборки.
Сложной онтологии связей в ТС и нет, по существу. Но та базовая, что есть — исключительно к месту.
теговая система конечно же полезна, но просто сам Tagsistant сейчас не пользуюсь, а на будующее было бы полезно применять ее совместно с распределенным хранилищем типа ipfs(ввиду того, что неудобно работать с хешами)
Это да. Даже сами разработчики предупреждают, что система стабильна, но стоит чему-то произойти в хостовой системе, целостность файла с БД может нарушиться и все насмарку.
Я люблю консоль и консольные утилиты, но не проще ли приспособить под хранение и иерархию тегов какое-нибудь внешнее хранилище, например, графовую бд?
Почему консольные? Графические браузеры файлов нормально работают с tagfs, в том-то и половина задумки. :)
Обычные файловые операции интерпретируются Тагсистантом в свои функции, благодаря этому, как отдельно отмечают разработчики, стандартный файловый диалог отлично работает с tagfs.
Внешнее хранилище, БД? Под хранение и иерархию тегов? Так ведь тут они как раз во внешней БД и хранятся.
Насчет файловых операций — признаю, тут вы правы.
Но как бэкенд сисетма использует sqlite & mysql, если я правильно понимаю зависимости. Мне кажется, что специальная графовая база была бы лучше.
Плюс не снесет ли подключене этой фс алгоритмы встроенным поисковикам: например, в kde поиск любит все кэшировать, читать тэги, писать свои и тому подобное
А у меня с тегами всегда одна проблема — со временем забываю какими точно тегами я тегировалэ хотя ls и grep по директории с тегами должны частично решить эту проблему.
fbi 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. вроде, уже была статья про tagsistant
Похоже. Ну дык, принцип-то базовый. А файлы пока еще все целиком в вебе не лежат и приходится к ним локальный огород городить...)))

Была, была, но меня она не удовлетворила.
фоточный хлам часто состоит из фоток, собранных из разных источников. с большой вероятностью в них найдутся файлы с «обобщенными» названиями (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
Насколько я помню, если имена у файлов одинаковые, а содержание разное, то система это распознает и даст файлам префиксы с номером их инода. Она проверяет контрольную сумму содержания, если они у двух файлов совпадают, то она берет только один, а на имя столько внимания не обращает.
Это не совсем в тему статьи, но встроенное в OS X приложение photos запросто ищет по запросу Koeln, street name, person name, 2010, December без настроек тэгов.
Через EXIF?
Да. Плюс встроенное распознавание лиц, которые, впрочем, всё равно нужно подтверждать вручную :)
Статья отличная — спасибо автору!
А создатель проекта — вообще молодец :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории