Tagsistant：セマンティックファイルシステム

こんにちは ハブには既にTagsistantに捧げられた資料がありましたが、私には一貫性がなく不完全であるように思われました。 別の方法でそれを提示するこの試みは、英語のマニュアルと私自身の観察からの短い絞りです。



Tagsistantプロジェクトは、その作成、tagfsを一般的な傾向に従って配置します。 彼らはインターネットを段階的にセマンティックトラックに変換しようとしています。プロジェクトの作者によると、ファイルシステムは時代遅れの原則に基づいています-階層、ディレクトリ、 それだけです。

そして原則として、私は彼らに何かに同意します。 数百枚の写真があり、そのうちのいくつかはケルンで撮影され、他は日没で撮影され、3枚目は女の子、4枚目は2010年に撮影されたと想像してください。 次の操作を実行するとします。2010年に撮影されたものを除く、ケルンで日没時に撮影された写真のリストをガールフレンドと一緒に取得します。

はい、おそらく誰かが言うでしょう、たとえば、 Koeln、sunset、girls、2010などのディレクトリを作成し、それらにファイルへのソフトリンクを送信できます...そのようなものですが、リクエストをコンパイルするのに必要な柔軟性と利便性を提供します（ただし上記の例の解決策になりますか？）

はい、EXIFタグを使用してみてください。 しかし、カメラは写真の中の女の子の存在やあなたの想像力によって制限される他の基準を彼らに示しません。 そして、それが写真についてではなく、 レポートについてですか？

setattr \ getattrを使用して、ext4を使用してファイル属性に固有のタグを記述しようとすることができます-少なくとも、ファイルのタグ付けの問題でこのような文を見ましたが、試していません。 しかし、これはうまくいくとしても、中途半端な決定でもあります。

私のニーズに基づいて思いつくことができる本当の種の例。 私は、ダウンロードに保存され、後でテストされた（実際には、1つではない）膨大な量の異なる画像ジャンクを含むフォルダーを持っています。 この埋め立て地から、キエフで作られたビールの画像が含まれ、2012年以前に作られたフォーラムの女の子の写真のリストを取得したいと思います。 彼らと一緒に、私が持っているすべてのフォーラム管理者の画像を取得したい：

$ ls〜/ tagsistant / store / forum / girls / beer / = Kyiv / time：/ year / lt / 2012 / + / admin / @ /

tagfsが提供するものを検討してください。

最初は、ファイル、ディレクトリ、デバイス、さらにはパイプ（！）にタグを付けることです 。 2つ目は、タグ間の関係です。タグには、include、exclude、equivalent、requireがあります。 ファイルは/ archive技術ディレクトリに保存され、タグは/ tagsに保存され、 タグに一致するファイルは/ storeディレクトリに保存されます。 合計ディレクトリ6：

エイリアス/アーカイブ/関係/統計/ストア/タグ/



可能な限り多くのタグを含めることができます（合理的な制限内）。 ファイルにタグを付けるための構文は次のとおりです。

$ ln -s〜/ foto1.jpg〜/ tagsistant / store / koeln / wife / sunset / @

写真は、「ケルン」、「妻」、「日没」の3つの独立したタグのセットに帰属します。 これで、この写真は、これらのタグのいずれかの選択、およびそれらの任意の組み合わせに分類されます。



なぜln -sで、最後に「後背位」なのでしょうか？ まず、なぜですか？ ファイル自体が既に存在し、ファイルとタグの間に対応関係を作成するだけで、ファイル全体をコピーし、コピーするためにより多くのスペースと時間がかかるのはなぜですか？

次に、 @記号は一連のタグの終わりを示すマーカーとして機能します。 パス内のTagsistantはtagfsのマウントポイントを指し 、 ストアディレクトリはファイルをタグに直接関連付けてアクセスするために使用されます。 さらにすべては、ファイルに関連付けられた一連のタグです。 ここで、タグの異なるセットでさらに10個のファイルを追加したと想像してください。一部には/ 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 / @ /

結果：ケルンの写真と日没の写真。 これらのタグの重ね合わせではなく（日没時にケルンで撮影された写真）、2つの異なるサンプル（1日の任意の時間にケルンの写真と絶対に任意の場所で撮影された日没の写真）の合併です。

$ ls〜/ tagsistant / store / koeln /-/ sunset /-/ wife / @ /

同様に、日没で撮影されたものを除き、ケルンのすべての写真。 そして妻も、釣りの写真だけが必要です。 :)

（ + +融合演算子はまったく同じように機能します。各演算子は後続のタグを1つだけ参照するため、3つのタグの融合をマージするには2つの演算子が必要です。）

中括弧はタグをグループ化するために使用されます。 3セットのファイルを選択する必要があるとします。 最初のセットは「スターウォーズ」と「イメージ」として、2番目は「スターウォーズ」と「音楽」として、3番目は「スターウォーズ」と「ビデオ」として同時にテストされます。 マージ演算子を使用すると、これは次のように表現できます。

$ ls〜/ tagsistant / store / starwars / image / + / starwars / music / + / starwars / video / @ /

しかし、それは良いです：

$ ls〜/ tagsistant / store / starwars / {/ image / music / video /} / @ /

より高度な使用例には、次のクエリ例が含まれます。

$ ls〜/ myfiles / store / {/ starwars / startrek /} / {/画像/音楽/ビデオ/} / @ /

これにより、2つの異なる映画に関連するすべての写真、音楽、およびビデオのセレクションが提供されます。 グループ化せずに作成された同等のクエリは次のようになります。

$ ls〜/ tagsistant / store / starwars / image / + / starwars / music / + / starwars / video / + / startrek / image / + / startrek / music / + / startrek / video / @ /

グループ化されたタグには他のグループを含めることはできません（タググループでできないのは、それらをネストすることだけです） 。 また、ブラケットのペアを観察し、それらを閉じることを忘れないでください。

ファイルタグとALLメタタグの列挙

自然に期待されるもう1つの機能は、ファイルに関連付けられているすべてのタグを一覧表示することです。 それを取得するには、 catコマンドを使用して、サフィックス".tags"が付いたファイルにアクセスする必要があります。 このように：

$ cat tagsistant/store/koeln/@/photo1.jpg.tags

ケルン

妻

日没

画像

これは、ファイルに関連する少なくとも1つのタグを覚えている場合です。 そうでない場合、メモリは完全に消えましたか？ グローバルメタタグALL /は役立ちます。 結果は同じです。

$ cat tagsistant/store/ALL/@/photo1.jpg.tags

ALLメタタグはtagfsに含まれるファイルの完全なリストを提供し、たとえば、従来の階層システムのようにストアフォルダーの再帰処理が機能しないため、 すべてのファイルの自動処理などに役立ちます。 または、上記のように、特定のファイルにタグを付けたことを覚えていますが、そのタグは覚えていません。 それらのリストを表示するには、共通のメタタグを使用します。

トリプル（複合）タグ

おそらく、フラットタグで終わり、名前空間とトリプルタグに移る時が来たのでしょう。 前の例は優れた柔軟性を示していましたが、一定の制限があります。 私は自分の自転車を発明せず、マニュアルの例を取り上げます。年ごとに差別化したタグを導入したいとしましょう。 これを実装するにはどうすればよいですか？ 2000 、 year_2000などのタグを作成します。 各年のタグで。 これにより、タグディレクトリが乱雑になり、さらにタグ名が衝突する可能性があります。

構造化と使いやすさを追求したtagfsのタグ開発の第2レベルは、次のような3つの要素のタグの構成で表されます。

名前空間-キー-値

名前空間は、含まれるキーと値のペアのセマンティックアフィリエーションを記述し、非常に一般的な場合があります 。たとえば、特定の例では、名前空間 timeを使用できます。 キーは年のように見えますが、特定の数値は値の 3番目の要素に含まれます 。

実際の使用では、複合タグに別の要素があります： operator 演算子のリストから、それらの役割が明らかになります： eq （等しい）、 inc （含む）、 gt （より大きい）、 lt （より小さい）。 したがって、複合タグの完全なスキームは次のようになります。

名前空間：/キー/演算子/値/

名前空間の後のコロンに注意してください。これは必須であり、このスペースを定義するだけの役割を果たします。



したがって、タグディレクトリを乱雑にすることなく、写真を年、月などで分類することもできます。 2010年8月にケルンで撮影されたケルンのタグの写真を使用して、ディレクトリ内のすべての写真に帰属すると、次のようになります。

$ 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に対して、画像タグ、mp3-flac-音楽などを提供します。 そのような機能がプロジェクトに組み込まれているかどうかはまだ明らかではありません。おそらく、そのような機能を持つ独自のプラグインを作成できます。

関係について

それらの4つだけがあります： include、exclude、is_equivalent 、 requires 。 標準マニュアルには、それぞれの詳細な説明はありません。 例は1つだけです。

$ mkdir〜/ tagsistant / relations / TAG1 / includes / TAG2 /

このような関係を作成した後、 TAG1への要求は、タグTAG1とTAG2の両方を持つファイルのリストを生成します。 実際の使用例-imagesタグには写真が含まれます 。 2014年のロンドン旅行中に、いくつかの写真を撮り、同時にインターネットからいくつかの写真をダウンロードしたとします。 それらのいくつかはbashorgのコミックであり、一部は壁紙です。 ある時点で、その期間のロンドン（/ London / photos /）の写真を壁紙（/ images /）と一緒に見たいと思っていましたが、漫画（/ comics /）で時間を無駄にしたくありませんでした。 次に、クエリは次のようになります。

$ ls〜/ tagsistant / store / London / images / time：/ year / eq / 2014 /-/ comics / @ /

除外は安定していて明白です。 セットAに はセットBが 含まれ （含まれ）、セットBにはCが含まれません。 ここで、 fileA （タグA ）、 fileB （タグB ）およびfileC （タグBおよびC ）の3つのファイルがある場合、タグAのリクエストはfileAおよびfileBを返し 、 fileCは検索から除外されます。 fileCは、 Cタグに直接アクセスすることによってのみ取得できます。

クエリ/ストア/ A / + / B /-/ C / @ /も同様に機能します。 関係により、長期的な関係を確立し、問い合わせを減らすことができます。



標準マニュアル以外のソースからは、 is_equivalentリレーションが最も明白でシンプルな機能を持っていることが明らかになります。推論のブロックから見ると、あるタグを別のタグと同等にします。 そのような例がありました：ビートルズはthe_beatlesと同等になり、2番目の例は、誰かがmy_homeのようなボトムラインを使用するタグを好まないかもしれないという推論の背景にmy_homeをmy \ homeと同等にしました。 なぜ-それは明確ではありません。 （これは私の意見です。）



必要とする最も明白なことは、ファイルシステム階層内の1つのタグを別のタグ内に隠すことです。 つまり、たとえば、次を実行する場合：

$ mkdir〜/ tagsistant / relations / TAG1 / require / TAG2 /

$ ln -s〜/ somefile.txt〜/ tagsistant / store / TAG1 / @ /

その後、タグTAG1でsomefile.txtにアクセスできるようになりますが、 ストアディレクトリのタグリストには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＃ つまり、ファイルには1つのタグのみがタグ付けされます

これらのタグ間の関係が存在しない場合、TAG1は最上位のstore /ディレクトリに含まれます。 これまでのところ、この関係の深い存在論的意味は私には届いていません。 不十分な説明では、実際には描かれていません。

UPD：プロジェクトのChangeLogで、 requiredと呼ばれる新しい関係についての言及を見つけました。 文字通り、そこは次のように言われています（英語からの翻訳） ：

「必須」関係が導入されました。 タグSにタグMが必要な場合、タグMは、タグMがリクエストの最後の位置に含まれている場合にのみ表示されます。例：

店舗/ M /

店舗/ P / Q / + / M /

ただし、以下には表示されません。

店舗/ P /

店舗/ P / + / Q /

この関係の目的は、タグを階層構造に整理して、ルートディレクトリの混乱を防ぐことです。 ある程度、名前空間の機能を補完します。

正直なところ、明確さはありませんでした。 少なくとも、説明されている動作は確認していません。 たぶん私は何かを理解していません。

ホイールの重複排除とその他のスティック

重複排除は、同じファイルがファイルシステムで2つの異なるiノードを使用するのを防ぐメカニズムです。 これは、フラグとして空の一時ファイルを作成するジョークはここでは機能しないことを意味しますが、これは必要ではありません-これは補助的な専用システムです。

次のようになります。

$ touch〜/ tagsistant / store / tag1 / @ / tempfile1

$ touch〜/ tagsistant / store / tag2 / @ / tempfile2

$ touch〜/ tagsistant / store / tag2 / @ / tempfile3

これらの操作の結果は、タグtag1とtag2が割り当てられたtempfile1のみになります。 他の2つのファイルを作成しようとすると、コンテンツの検証が行われます。最初のファイルと同じファイルがあり（すべて等しく空です）、最後のペアに割り当てられたタグは同じ名前の最初のファイルに割り当てられます。

推論システムの無効化（思考のブロック）

@記号を使用したリクエスト内の一連のタグの完了は、前述のブロックを「オン」にし、すべてのリクエストロジックを完了するように強制します。2つの文字@@ 「オフ」を使用します。 いくつかの場合に役立ちます。その中には、個別のファイル操作と、関係を伴わないタグに関連付けられたセットの表示があります。 たとえば、タグAにタグBが含まれている場合、タグAへの要求に応じて、システムは両方のセットを表示します。 同様のリクエストで囚人をオフにすると、セットAのみが取得されます。

$ ls〜/ tagsistant / store / A / @ /

Afile1 Afile2 Bfile1

$ ls〜/ tagsistant / store / A / @@ /

Afile1 Afile2

エイリアス

おなじみのタグチェーンは、 =で示される短いエイリアスで非表示にできます。 エイリアスに関連付けられたクエリチェーンはそのまま置き換えられるため、結果としていくつかのトリックが発生する可能性があります。 エイリアスは、関連付けられたクエリ文字列を含むファイルとしてエイリアスディレクトリに保存されます。 behemothという名前のエイリアスファイルに文字列behemoth / file：/ format / eq / AVI /が含まれているとします。 将来的には、より一般的なリクエストに置き換えます：

$ ls〜/ tagsistant / store / = behemoth / time：/ year / lt / 2000 / @ /

前述のキャッチは、エイリアスに+ /演算子が含まれている場合、エイリアスに続くクエリの部分全体が2番目の部分にのみ適用されるという事実から成ります。 ところで、マニュアルでは、オペレーターはそれに続く1つのタグのみを参照すると言われているため、完全に明確ではありません。 おそらく、情報には、別のイノベーションの後に更新する時間がありませんでした。

タグのマージ

また重要な部分は、言及するしかありませんでした。 2つのタグを1つにマージするには、一方のディレクトリの内容全体を他方のディレクトリに転送するだけです。 そして、最初のものを削除します。

$ mv store / merged_tag / @ / * store / destination_tag / @ /

$ rmdirタグ/ merged_tag

同様に重要な注意。 / storeディレクトリ内の空でないフォルダを削除しないでください 。 各タグの各ディレクトリには、他のすべてのタグ（それらのディレクトリ）へのリンクが含まれているため、1つのタグのフォルダを削除すると、リポジトリ全体が破壊されます。 / storeフォルダー内のすべての削除は、完了した要求でのみ可能です。 思考リゾナーのマーカー@または@@が含まれている場合、リクエストは完了します。 この場合、リクエストにリストされているタグへのアクセスの結果となるファイルのみが削除されます。

タグを削除するには、 / storeディレクトリではなく/ tagsディレクトリにアクセスする必要があります。 このタグが割り当てられているすべてのファイルはそのまま残りますが、対応するタグは失われます。

組立

Tagsistantは、LinuxまたはBSDでビルドするように設計されており、glib2、fuse、libdbd-sqlite3、libdbd-mysql、libextractorプラグインを備えたlibdbiライブラリが必要です。 デスクトップディストリビューションがないため、依存関係の半分を手動で収集しました。 同時に、Tagsistantはsqlite3ヘッダーのみと一緒になりました（実際、ご覧のとおり、彼にとっても十分です）が、ガベージメッセージが表示されます。 おそらく、mysqlヘッダーなしでアセンブルしたからでした-起動後、作業中に、 「ステートメントにテーブルがありません！」などのメッセージが端末に送られます。 標準出力をアストラル1> / dev / nullにリダイレクトするだけで十分です。これにより、作業に目に見える影響がありません。



もちろん、だれかが「フォルダの階層を整理できるのに、なぜこのバイクなのか」という精神で言うことができます。 フォルダの階層は、このような柔軟性と利便性を提供するものではなく、思いついただけのリクエストを絶対に尋ねることができると信じています。 さらに、私の観点からは、階層、リンクなどと同様の大騒ぎが繰り返されています。 写真付きの例が原因で誰かに偶然発生した可能性のあるEXIFタグは、チャットアーカイブやTagistantがタグ付けできるすべてにタグを付けるのに適していません。 システムには多くの開発が必要ですが、 すでに便利で安定しています。 彼女に注意してください。