ちょっとしたメモ

FlickrがMachine tagsを実装したというアナウンスがあり、某界隈で話題になっている。これは、従来のタグの書式を拡張して、medium:paint=oilという具合に「名前空間:プロパティ=値」というトリプルタグ（！）を用いてより詳細なタグ付けをし、API経由で処理できるようにするというものだ。一見「おぉ、これは」という感じだが、実際のところはどうだろうか。

まず、ここで「名前空間」はmedium:と名前空間URI接頭辞のような形式になっているが、実際はプロパティや値と同じくユーザが任意に与えるラベルになる（後述のようにURIと結びつける方法があるとされているが、怪しげ）。dc:とかfoaf:といったよく使われるものは収斂していく可能性は高いものの、「Machine tags」と呼ぶにはちょっと弱い。が、まぁそこは「タグ」の世界だから、いいことにしよう。

少しまともなプロパティを与えようとすると、値がリテラルではたいしたことができないのはすぐに気がつく。文字列ではマージができないばかりでなく、そこでグラフが終点になってしまって、情報の連鎖を記述できないからだ。一方で、例を見ると、

geo:cartier="plateau mont royal"
geo:neighbourhood=geo:cartier

というように、値も「名前空間」修飾して、別のタグとしてその値に関する記述をしているように思われるところもある。しかしこうなると、geo:cartierというのは主語（写真）のプロパティなのか、独立したリソース（主語/目的語）なのか訳が分からなくなり、構文の限界が露呈してしまう。

これは、「名前空間」とURIをマッピングする例として示されている方法も同様だ。

dc:subject=tags
xmlns:dc=http://purl.org/dc/elements/1.1/

こうやってdc:のXML名前空間URI宣言を行うというのだが、2行目は写真が「xmlns」名前空間の「dc」プロパティを持ち、その値が「http://purl.org/dc/elements/1.1/」ということでもある。構文規則をきちんと決めないと、処理は難しいだろう（まだ実験段階ということだから、今後に期待できる部分はある）。

＊

技術的な問題はさておいて、試しに「Machine tags」を使ってみようとflickrのページを見ながら2日ほど考えてみた。しかし、これぞというアイデアは浮かばなかったというのが率直なところ。 タグはもともと主語（写真）に関するトピックやキーワードというプロパティとして理解されるわけだから、それを「dc:subject」としても仕方がないし、「dc:title」はFlickrページで既に与えている。写真の撮影情報はExifで記録されているからタグとして記述する必要はない。例に挙げられているmedium:paint=oilなんてのは、実は被写体に関する情報で、写真の「Machine tags」として与えると柔軟な解釈ができないマシンにとってはかえって厄介になる。

こうした違和感を持つのは、タグは主語と何らかの概念を緩やかに結び付け、それが「タグ」として束ねられているからこそ面白いということなのかな（その関係をタグ・オントロジーで辿るのは、簡単ではないが）。プロパティを任意に詳細化すると、その良さが縛われてしまうような気もする。

といっても、「Machine tags」のような試みを全く否定している訳ではない。例えば、del.icio.usのタグにdc:dateやdc:creatorを与えて、「タグをいつ誰が与えたか」ではなく「タグ対象のリソースをいつ誰が作ったか」を記述しておくのは意味があるように思う（AmapediaのFact tagもこの延長で考えられるだろう）。API経由でプロパティを指定して絞り込んだり、ワイルドカードを使った検索ができるというのも、新しい可能性を開くものなのかも知れない。

結局、Dan CattがFlickr Ramps up Triple Tag (Machine Tags) Supportで書いているように、これはNQRDF (Not Quite RDF forced into tags) なんだから、ぬか喜びする方がいけないということか。