| タグシスタント | |
|---|---|
| 開発者 | Tx0 <[email protected]> |
| 安定版リリース | 0.6
|
| 書かれた | C |
| オペレーティング·システム | Linuxカーネル |
| 入手可能な | 英語 |
| タイプ | セマンティックファイルシステム |
| ライセンス | GNU GPL |
| Webサイト | |
| 開発者 | 送信0 |
|---|---|
| 他の | |
| サポートされている オペレーティングシステム | リナックス |
Tagsistantは、 C言語で記述され、 FUSEをベースにしたLinuxカーネル用のセマンティックファイルシステムです。ディレクトリ階層を用いてオブジェクトを特定する従来のファイルシステムとは異なり、Tagsistantはタグの概念を導入しています。
階層型ファイルシステムの設計と違い
コンピュータ科学において、ファイルシステムとは、ファイルの保存、取得、更新に使用できるデータストアの一種です。各ファイルはパスによって一意に特定されます。ユーザーはファイルにアクセスするために事前にパスを知っておく必要があり、パスには必ずしもファイルの内容に関する情報が含まれているわけではありません。
Tagsistantは、タグに基づく補完的なアプローチを採用しています。ユーザーはタグのセットを作成し、それらのタグをファイル、ディレクトリ、その他のオブジェクト(デバイス、パイプなど)に適用できます。そして、クエリと呼ばれるタグのサブセットに一致するすべてのオブジェクトを検索できます。この種のアプローチは、画像、音声録音、動画、テキスト文書などのユーザーコンテンツの管理に適していますが、システムファイル(ライブラリ、コマンド、設定など)とは互換性がありません。システムファイルでは、パスの一意性がセキュリティ要件となり、不正なコンテンツへのアクセスを防止します。
tags/ディレクトリ
Tagsistant ファイル システムには、次の 4 つの主要なディレクトリがあります。
- アーカイブ/
- 関係/
- 統計/
- タグ/
タグはディレクトリのサブディレクトリとして作成されtags/、次の構文に準拠するクエリで使用できます。
tags/subquery/[+/subquery/[+/subquery/]]/@/[1]
ここで、サブクエリはディレクトリとして連結されたタグの無制限のリストです。
tag1/tag2/tag3/.../tagN/
パスのうち、とで区切られた部分tags/が@/実際のクエリです。この+/演算子は、異なるサブクエリの結果を1つのリストに結合します。この@/演算子はクエリを終了します。
次のクエリの結果として返されます。
tags/t1/t2/+/t1/t4/@/
オブジェクトは と の両方t1/、またはとt2/の両方としてタグ付けされている必要があります。またはとしてタグ付けされているが としてタグ付けされていないオブジェクトは取得されません。
t1/t4/t2/t4/t1/
クエリ構文は、パストークンが自身の子孫となることを許可することで、POSIXtags/t1/t2/+/t1/t4/@ファイルシステムのセマンティクスを意図的に違反しています。例えば、 where が2回出現する例がこれに該当します。その結果、タグ付きファイルシステムの再帰スキャンは、 Unixt1/と同様に、エラーで終了するか、無限ループに陥ります。
find
~/tagsistant_mountpoint$タグを 見つける /
タグ/
タグ/ドキュメント
タグ/ドキュメント/+
タグ/ドキュメント/+/ドキュメント
タグ/ドキュメント/+/ドキュメント/+
タグ/ドキュメント/+/ドキュメント/+/ドキュメント
タグ/ドキュメント/+/ドキュメント/+/ドキュメント/+
[ ... ]
この欠点は、クエリ内でタグを任意の順序で並べることができるという点で相殺されます。クエリはtags/t1/t2/@/と完全に等価でありtags/t2/t1/@/、tags/t1/+/t2/t3/@/は と等価ですtags/t2/t3/+/t1/@/。
この@/要素の目的は、POSIX セマンティクスを復元することです。つまり、パスはtags/t1/@/directory/従来のディレクトリを参照し、このパスの再帰スキャンが適切に実行されます。
推論エンジンと関係/ディレクトリ
Tagsistantは、関連タグが付けられたオブジェクトを含めることでクエリの結果を拡張するシンプルな推論機能を備えています。2つのタグ間の関係は、ディレクトリ内で3つのレベルのパターンに従って確立されますrelations/。
relations/tag1/rel/tag2/
要素は、includesまたはis_equivalent のrelいずれかです。rock タグをmusicタグに含めるには、以下の Unix コマンドを使用します。
mkdir
mkdir -p relations/music/includes/rock
推論エンジンは関係を再帰的に解決できるため、複雑な構造を作成できます。
mkdir -p relations/music/includes/rockmkdir -p relations/rock/includes/hard_rockmkdir -p relations/rock/includes/grungemkdir -p relations/rock/includes/heavy_metalmkdir -p relations/heavy_metal/includes/speed_metal
ディレクトリ内に作成された関係のウェブは、オントロジーrelations/の基本的な形式を構成します。
自動タグ付けプラグイン
Tagsistantは、ファイルまたはシンボリックリンクが書き込まれたときに呼び出される自動タグ付けプラグインスタックを備えています。 [2]各プラグインは、宣言されたMIMEタイプが一致する 場合に呼び出されます。
Tagsistant 0.6 でリリースされた動作するプラグインのリストは次のものに限定されます:
<title>text/html:および<keywords>要素の各単語と、document、webpage、htmlでファイルをタグ付けします。- image/jpeg: 各Exifタグでファイルをタグ付けする
リポジトリ
archive/各Tagsistantファイルシステムには、オブジェクトが実際に保存されるディレクトリと、SQLitetags.sqlデータベースとしてタグ付け情報を保持するファイルを含むリポジトリが存在します。引数でMySQLデータベースエンジンが指定された場合、このファイルは空になります。別のファイルは、リポジトリ設定を含むGLibのiniストアです。 [3]--dbtags.sqlrepository.ini
Tagsistant 0.6 は、タグ推論とタグ付け解決において、MySQL および Sqlite の SQL 方言と互換性があります。他の SQL 方言へのロジックの移植は可能ですが、基本的な構造(特に SQL キーワード INTERSECT)の違いを考慮する必要があります。
archive/ および stats/ ディレクトリ
ディレクトリarchive/は、タグを使用せずにオブジェクトに素早くアクセスできるようにするために導入されました。オブジェクトは、inode番号のプレフィックス付きでリストされます。[4]
このstats/ディレクトリには、使用状況統計を含む読み取り専用ファイルがいくつかあります。ファイルには、configurationコンパイル時の情報と現在のリポジトリ設定の両方が保存されています。
主な批判
タグやタグ付け情報を保存するために外部データベースに依存すると、データベースが破損した場合にメタデータが完全に失われる可能性があることが指摘されています。[5]
フラットな名前空間を使用するとtags/ディレクトリが過密になる傾向があることが指摘されています。[6]これはトリプルタグを導入することで軽減できます。
参照
参考文献
- ^ 「tags/ および relations/ ディレクトリ」。
- ^ 「Tagsistant のプラグインの書き方」。
- ^ 「キー値ファイルパーサー」。
- ^ "Tagsistant 0.6 の使い方 - Inodes".
- ^ 「拡張属性とタグファイルシステム」。
- ^ 「このアプローチの主な問題はスケーラビリティです」。news.ycombinator.com。
外部リンク
- 公式サイト
- Arch Linux パッケージはWayback Machineに 2019-08-28 にアーカイブされています
- Hacker Newsでの議論
- 拡張属性とタグファイルシステム
- タグシスタント・オン・プロダクション