OpenMeta総合スレ

ファイルシステム拡張属性を使ったメタデータの共通規格、OpenMetaについて語るスレ
Ironic http://www.ironicsoftware.com/
Project http://code.google.com/p/openmeta/

関連スレ
[ｽﾏｰﾄﾌｫﾙﾀﾞ]Spotlightを使いこなそう! 4[検索]
http://pc11.2ch.net/test/read.cgi/mac/1203059455/
Macで効率的な情報整理 4
http://pc11.2ch.net/test/read.cgi/mac/1218890988/

アップルだけだぞ。これほど多量の前科があるのは。 他社とは桁違いの不祥事の量だ。
注目すべきは不具合の多さとその対応の遅さや酷さ、放置して逃げたものもある。 つまり常習犯だよ。
他社とは違うのだよ他社とは。アップルなんかと一緒にされちゃどんな企業もかわいそうだ。

Yosemite前期型 → ATA部位に不具合 → 放置
PowerBook G3 Series → アダプタから発煙の危険性 → 期間限定無償交換
Lombard → メモリモジュールの不具合 → 放置
Pismo前期型 → ロジックボードの虚弱体質 → 放置
Cube → 電源部から発火のおそれ → 期間限定無償修理＋筐体のウェルドクラック(熱収縮ヒビ割) → 金型の跡と放置
初代AirMac → コンデンサ虚弱体質で寿命が一年説 → 放置
eMac&箱iMac → CRT画面が上下からかなりの割合で縮む → 放置＋グラボがへたれる虚弱体質、上記と関連？ → 放置
DualUSB他 → グラボがあぼーんする時限爆弾 → 期間限定無償修理（何度やっても爆発）
初代Titanium → バッテリが落下する → 期間限定無償処置？＋鬼発熱で膝の上で使うと低温やけど、高温による変色 → 放置
初代大福 → 液晶モニタが数センチ斜める → 放置
TitaniumP88"以降？ → ホワイトスポットで一部液晶がヘンになる → のらりくらり対応
Gigabit Ethernet → 特定条件下でカーネルパニック続発 → 原則放置
Mirrored Drive Doors → ファンが爆音 → ファームウェア＆静粛ファン送付
FW800 → メモリモジュールの不具合の可能性 → 完全無視
iBook→バッテリー爆発
PowerBook G4→バッテリー爆発
sawtooth→FWのプラグ＆プレイの突入電流でFW死亡→放置
iMac G5 → 奇声を発する → 放置＋ コンデンサ潮吹き＋熱設計ミスにより常に超高温動作→熱暴走＝短命化
iPod →　ウィルス混入＋爆発＋バッテリー持続時間を本来より長く表示する嘘＋液晶傾き＋クリックホイールの膨らみ
MacBook→ 充電機能の不具合でバッテリー爆発＋突然電源が落ちる＋アダプターが発火＋謎の黄ばみ＋謎のひび割れ＋訴えられるほど酷い糞液晶

今年初めて立てたスレの2がドザとかね、もうね

ドザって何ですか？

>>2
pismoとかlombardとかって１０年以上の前のネタをよく覚えているな。
そんなにMacが好きなん？

必死こいてネガキャンしてるアンチもキモイが、ドザって言葉もキモイ。

>>1乙!
Taggs使い始めた。
このジャンルは工夫のしがいがありそうだ。

まぁあっという間に落ちると思うが…いちおう支援。

# 誰かTiger用タギングツール作ってくれんかのぅ。

sawtoothってのは初耳だった
最近のネタはiPodだのMacBookだのずいぶんおおざっぱだな

コレってリソースフォークとかじゃなくて、ファイルに追加書き込みを行うんだよね？

>>10
いいえ
xattrです

http://veadardiary.blog29.fc2.com/blog-entry-2056.html
http://pc11.2ch.net/test/read.cgi/mac/1203059455/274-280 および
http://pc11.2ch.net/test/read.cgi/mac/1218890988/345以降にいろいろ書いてる

Tagsクーポン付きで買ったよ。ここはサポートが早くていいね
俺がいくつかリクエストしたやつが、次のバージョンでつけるから待っててねって言われて今からwktk中

問題は少し高いところか

キモいからドザなんだわな

やっぱ対応アプリが増えないと盛り上がらんのかな

マイナーなアプリ＆ベンダーの仕様だからね。
Adobe や Apple が採用してくれれば、一気に盛り上がるんだろうけど。

でも意外と対応アプリ広まりそうよ

2chブラウザで採用してくれれば面白そうなんだがな

使い始めたのはTagitだった
間違えた
Tagsも使って比較してみる

>>17
>でも意外と対応アプリ広まりそうよ

フリー＆シェアウェアの作者や小規模ベンダの対応は早いかもしれない。
ただ、対応アプリが増えてくると、今度はタグの語彙の統一という課題が。
人名だけでも Author/Creator/Producer/Writer/Composer/Actor/
Musician/Player/Transrator..... これらを各ベンダが勝手に
割り当てるんじゃなく、一貫した命名規約が求められるようになると思う。
今は仕様開発元のベンダが決めた独自仕様だけど、彼らが他のベンダとの
意見調整を上手に集約していくことができるかが、鍵になると予測してる。
その意味でも仕様策定に慣れた大手ベンダの参入は大事になる。

個人的には Dublin Core(ダブリンコア) をベースにしていたなら、
先の広がりが見えて良かったとのに、と思っている。
オープンかつ草の根的な活動、しかも実装仕様としては適切であり、
とても期待してるのだけど、その語彙の課題だけが残念なところ。

>>20
いや、その辺はOpenMetaの仕様で統一されてるんだけど

>>21
現在の仕様は開発元ベンダのアプリで使用されているタグ仕様を
ベースとしていて、開発元は「意見を募集中！」としているというのが、
現状だと認識してる。漏れの認識は間違っているかな？

その「統一」とは、はたして決定的なものと断言できるものなのかな。
単なる API(実装)ではなくタグの語彙だから、製品の根幹にかかわる仕様なんだが。

>>22
他のベンダーが、独自にコードを書けば、OpenMeta標準外の属性を作ることなんて、簡単にできる。
ただその場合、OpenMeta標準アプリからアクセス出来ないというだけの話。そして、ここにこそ「OpneMetaを
使うインセンティブ」が存在する。

「他のアプリからも読み書きしてもらえた方が、自分にとっても便利だ」とdeveloperが思う限り、
独自の属性情報を使うインセンティブは存在しない。

属性の種類がどれだけ増えるのか、まだまだ暗中模索のレベルだと思う。

個人的には、「kOMUserTagにはユーザーが好きな語／フレーズを自由に書き込める」と
いうだけでひとまずの目標は達成されたので満足。そんな簡単なことですら、spotlight commentの時代には、
不安定で満足にできなかったのだから。

なんか良いアイデアがあったらIronicのフォーラムに書き込むよ。Dublin Coreの話はIronicのどっかに書き込んでおく。
ググったけれど、web上でメタデータの様式を統一しようとする試みから生まれたという理解でOK？他に、書くべきことは
ないかな？この方式のメリットとか、すでにどれだけ普及しているかとか教えてもらえると、書き込み安いのだけれど。

ぶっちゃけタグ付けって面倒でやる気がしない

海賊版「iWork '09」の中に、Macを標的にしたトロイの木馬
http://internet.watch.impress.co.jp/cda/news/2009/01/23/22189.html

今回の一件でわかったこと

AppleはMacのセキュリティに自信
→嘘であることが露呈、信用崩壊

Macユーザーは正規ソフトを使用していると主張
→海賊版利用者だらけなことが改めて裏付けｗ

>>23
>web上でメタデータの様式を統一しようとする試みから生まれたという理解でOK？
OK。もともとはインターネット上の全文検索システムを標準化する目的で
IETF が策定した仕様がベースになっており、Semantic Web や Web Ontology の分野では、
基盤となる共通語彙仕様として将来性は確定している。
とりあえず Dublin Core を採用している主要な標準規格とプロジェクトを列挙。
* RSS(RDF Site Summary)
　* Webサイトの更新情報に関するメタデータ。
* XMP(Extensible Metadata Platform)
　* PDF や 画像ファイル内に埋め込まれるメタデータ。
　* Extf を置き換えるもの。Adobe が原案を策定。
* NASA Taxonomy 2.0
　* NASA 内部で利用されている分類体系の公式標準仕様
　* http://nasataxonomy.jpl.nasa.gov/xml.htm
* junii2()
　* 国立情報学研究所の学術機関リポジトリ構築連携支援事業におけるメタデータ交換形式
　* http://www.nii.ac.jp/irp/
Dublin Core に関する情報としては、ネット上なら Wikipedia からリンクされている
Web KANZAKI 内のページ、あるいは以下のサイト(愛知淑徳大学図書館)が詳しい。
http://www2.aasa.ac.jp/org/lib/j/netresource_j/pf/pf_met-dc_j.html

>>23
>個人的には、「kOMUserTagにはユーザーが好きな語／フレーズを自由に書き込める」と
>いうだけでひとまずの目標は達成されたので満足。
同感。
というか、kOMUserTag だけをタグ仕様として定義していれば、問題は起こらなかった。
欲を出して、自社ソフト固有のタグ(の語彙)を追加したものだから....。

>この方式のメリットとか、
とにかく、既に存在している「特定ベンダに非依存」な標準仕様であることにつきる。
あと、MacOSX に閉じこもった世界から、Linux/Windows を巻き込んだWebワールドへの
展開が期待できること。(標準規格に対する姿勢の面で)

ちなみに フォーラム の hoge さんですか？

Snow LeopardのSpotlightがこれに準拠して
Tags をタグ付け機能として標準搭載してくれたらなあ

フォーラムのhogeさん精力的すぎワラタ
ユーザの鏡やね

>>24
>ぶっちゃけタグ付けって面倒でやる気がしない

のび太>
面倒だからコンピュータがファイルの内容とかをチェックして適切なタグ付けを
してくれればいいのになあ。ドラエもーん!

ドラえもん>
ぱぱぱぱっぱぱー 「すぽっとらいとー!」

さてと。
あれれもしかして、タグ付けって写真とかみたいな、データ自体からキーワードが
抜き出せない場合に（特に）重要?
しかし、写真は、画像認識で適当なタグを付けてくれんかのうw

あと検索の仕方も、何か人工知能的な連想マッチみたいのをしてくれると、
ありがたかったりして。カレー -> 食べ物　とか。

タグクラウド機能が欲しい。

OpenMetaのタグってiPhoneでも利用できるのかな？
将来Yepで付けたタグがiPhoneのPDFビューアで使えたら嬉しいんだけどな。

OpenMeta Enhanced
OpenMeta Enhanced Extra
OpenMeta Ehhanced Extra ver.2
OpenMeta Ultra

どんどん仕様が増えて互換性が薄れてく
パソコン界いつものパターンが予想されるw

>>30
>あれれもしかして、タグ付けって写真とかみたいな、データ自体からキーワードが
>抜き出せない場合に（特に）重要?
>しかし、写真は、画像認識で適当なタグを付けてくれんかのうw

iPhoto '09 だと「人々」機能で顔を画像認識して自動的にグループ化してくれるね。
このグループに付ける(人物の)名前が「タグ」に相当するのかも？
他にも Deep だと、画像分析で自動的にカラーラベル(一種のタグ)を付けてくれる。
どちらにしても、iPhoto や Deep が OpenMeta に対応してくれないと無意味だけど。

>あと検索の仕方も、何か人工知能的な連想マッチみたいのをしてくれると、
>ありがたかったりして。カレー -> 食べ物　とか。

これを実現するには、「カレーは食べ物の一種である」という関連をコンピュータ側が
知識として持っている必要がある。この例だと「X is a kind of Y」という関連。
他にも「福神漬けはカレーの一部である」を一般化した「X is a part of Y」という関連など。
こういう関連を体系化して、知的な情報検索(人工知能的な連想マッチ)を実現しようという
試みが、いわゆる Sematic Web と呼ばれるもの。
ただ、実用化はドラエモンの時代とはいかないまでも、かなり遠いと言われてる。

>>34
とりあえず、DeepはOpenMeta対応。ってかIronicの製品。
あとオントロジ系ってもう実用の域だと思うんだけど

>>35
>とりあえず、DeepはOpenMeta対応。ってかIronicの製品。

失礼、その通りだ

>あとオントロジ系ってもう実用の域だと思うんだけど

では、実用化された製品(ソフト)やサービスを挙げられるかい？
たとえば Google は賢い検索サービスかもしれないけど、
言葉の意味(Semantic)は理解してないからオントロジの応用とは言えない。

>>24
>ぶっちゃけタグ付けって面倒でやる気がしない

タグ付けは面倒かもしれないけど、メタデータとして一般化してみれば、
いたるところで普通に「メタデータ付け」をやっているんじゃないかな？
たとえば、iTune のジャンルやアーティストもメタデータだし、iPhoto の
アルバムもメタデータだよね。

ただ、問題は、せっかく入力したメタデータがそのアプリケーション内という
「閉じた世界」の中でしか利用できない事。

OpenMeta が目指しているのは、そんなメタデータを各アプリケーション間で
オープンに再活用できる枠組みの実現だと思う。(広義の「フレームワーク」)

言い換えると、OpenMeta が普及した世界であれば、各アプリケーションで
入力した分類情報が、そのままタグとして他の検索アプリケーション
(たとえば Spotlight)から再利用できるようになる。
ユーザからは「タグ付け」という行為自身は意識しなくてもよい世界だよ。

>>37
>各アプリケーションで入力した分類情報
>>24はその入力が面倒だって言っていると思われるので
その回答では無意味なのでは。

iTunesなどでcddbから自動取得するような方法で、
あらゆるデータに暇人あるいは営利団体がタグ付けしてくれる状態になれば
>>24も大満足だろうけど。

検索のエンジン側でもうちょいなんとかならんのかなという気はするなあ。
文書の検索に話を限ると、
もしエンジンの側で文書内容から判断して適当なグループに分類することができたら、
グループレベルのタグは手動で付けなくていいということにならないかな?

例えばスパムのフィルターって、要はスパム/非スパムという二つのグループにメールを
自動分別してるわけで、この延長で、もっと細かな分類はできないのかなと思ったりする。

ま、仮にグループ分けできても、それが人間にとってどういう意味のグループかを認識
するのは難しいかもしれんが、まずはプライマリーな単語でマッチして、さらにそれと似た
傾向を持つ文書を引っ掛けてもらえるだけでもありがたいような。
そのぐらいは Google とかならやってるのかな?

>>38
>>>24はその入力が面倒だって言っていると思われるので
>その回答では無意味なのでは。

たとえば、>>24 が iTune を使っていたとして、cddb から
自動取得できる情報だけで満足、自分で分類情報を入力するのは一切が面倒だ！
と思っているのなら、無意味という指摘は正しいと思う。

でも実際には、>>24 も iTune に手動で分類情報を入力してるんじゃねえの？
たとえば、レート(好み)やプレイリストなんかは、その個人の視点でしか
付けることができない「ラベル(=メタデータ)」だよ。
それすら(レート付け、プレイリスト分類すら)面倒なので、iTune で
それらの機能は利用してません！！と >>24 が言いたいのならしゃあないが。

言い方が乱暴でスマソ

頑に iTune

>>38
言いたかったことを以下にマトメます。

将来「あらゆるデータに暇人あるいは営利団体がタグ付けしてくれる状態」が
存在するようになったとしても、個人がコンピュータを利用している限り、
(意識的にせよ無意識にせよ)タグ付けという行為からは逃げられない。

そういうタグ至上主義的な発想には反対だな。
まあタグソフトのスレでそれをいうのは
野暮なのかもしれないけども。

>>43
野暮ですなw

仮にコンピュータを離れても「あいつはXXX主義者だ」とか
「奴はXX派だ」というレッテル張り(=タグ付け)からは逃れられません。
また、ある人物という主題が持つ名前(氏名)そのものも、
人物に付けられたラベル(=タグ)の一種です。

冗談はさておき、現状ではコンピュータの中の世界ですら、
タグ技術(メタデータ)が十分に活用されているとはいえません。
OpenMeta が、その先駆けになればいいなと思います。

とりあえず、タグとアトリビュートを混同してるような

>>39
いわゆる「テキストマイニング」や「文書分類」と呼ばれる
統計学をベースにした応用システムですね。クラスタ分析が代表的かな。

個人的には、(Google に代表される統計学を応用した)全文検索システムは、
膨大で不均質な情報源(=インターネット)に対して有効な手法だと思っています。
そのような情報源には画一的な分類体系が存在していないから、
全文検索に頼らざるをえない、という消極的な理由で。

ただ、一度 Mac に取り込んでしまった情報であれば、全文検索「だけ」に
頼る必要はないとも考えます。取り込んだ時点で既に一定のタグ(メタデータ)は
付加されているし、その後、人手で追加していくこともできる。
だから、第一はタグによる検索ではないかと思う。
そして第二の存在として、あまりに膨大になったMac内の情報源に対し、
付けたタグすら思い出せない状況下で(Spotlightのような)全文検索がある。

>>45
>とりあえず、タグとアトリビュートを混同してるような

とりあえず、タグとアトリビュートの定義をよろしく。
あと プロパティも含めてくれると嬉しい。

>>47
なんでironicのサイトにアクセスする努力をしないの？

>>48
意味不明。

ironic のサイトは見ているつもりだが、アトリビュートという言葉は
サイトのどこで定義されているのやら。
実装における EA(Extended Attribute) のことではないよね？

もしよろしければ、お教えくださいませ。

>>23です。ironicの中の人と、いろいろ話してみました。

http://ironicsoftware.com/community/comments.php?DiscussionID=630&page=1#Item_0

どうやら、メタデータ（属性）の種類に関しては、「まずはGoogle codeで『こんな属性を
追加したらどうか』と提案してもらい、開発にコミットした人たちの議論で決めて行く」
という方向で考えているらしい。

印象では、ironicの中の連中はかっちりとしたプランを持ってない感じ。
「何でも出来るから、みんな、google codeで意見を出し合って議論しよう」という状態だね。

一応、>>27が後半に書いたような話をしておきました。ただ、この意見はironicのforumに出すより、
google codeにissueとして挙げた方が確実だと思う。良かったら提案してみて下さい。
もし、英語がダメなら、ここに何を提案するか書いてもらえれば意訳してgoogle codeにissueとして書いておきます。

鬱陶しい海外ドメイン規制のせいで、ここに書き込むのは面倒だけれど、このスレで出て来た意見とかは見てるので
適当にironicの方にも書いたりしますから。

あと、最近、hotなスレはここか。

http://ironicsoftware.com/community/comments.php?DiscussionID=632&page=1#Item_0

Eaglefilerの開発者が出て来て「OpenMetaのコードは、Appleが公式には容認していない方法を使っている。
これでは、将来、Appleが方針を変えたら、ごっそりダメになってしまんじゃないか」という提案をしている。
技術的な話なので、どう転ぶのか分からないけれど、何か言いたい事があったら、適当に選んで書き込んでおくよ。

com.appleを勝手に使ってるわけだから、
それがずっと使えるという希望的観測に依存するのは
ちょっとあぶなっかしいだろう、ってことだね。

http://ironicsoftware.com/community/comments.php?DiscussionID=632&page=1#Item_26

これにあるようにorg.openmetaにも書いておく、
ってのは現実的かつ安全でいいんじゃないのかな。

>>49
はあ…
OpenMetaにおける属性（アトリビュート）はEAに記録されるメタデータのフィールド。
タグは単にkOMUserTagsアトリビュートの値でしかない。

この程度の理解もできてない奴がIronicのフォーラムにも出てきて議論の邪魔にもなった。

>>51
そのスレ上からあらためて読んでみたけど
Tsai氏の言ってることはしごくまともで俺はよく理解できるんだが
なんか盛り上がりに水をさされたようにとらえたのか
OpenMeta支持側が過剰反応しちゃってる感じだねえ。

>>54
途中からだんだんと明らかになってきたんだけれど、
org.openmetaにメタデータを格納するとspotlight検索が出来ないらしい。

確かに、skimも情報をxattrに格納するんだけれど、com.apple.metadataには
格納してないから、そのままではspotlight検索ができない。
それは、ユーザーにとって大きなデメリットだと思うよ。IronicのTomは、
その点を突いて来た。

だから、最後の方でMichaelも意見を変えて「com.apple.metadataとorg.openmetaの両方にタグを
格納すれば、両方のニーズが満たせる（spotlightで検索したいvs.appleの気が変わっても
メタデータが消えない場所に格納する）」と言い始めた。

最初は、彼は「com.apple.metadataは使わず、org.openmetaだけを使おう」と
言ってたのだから、それに比べれば、大きな進展だよ。

>>55
> org.openmetaにメタデータを格納するとspotlight検索が出来ないらしい。

Tsai氏が最初から指摘してるのは
「タグの共有」という目的にははcom.apple.*を使う必要がない(org.openmetaだけで可)。
でもspotlightに検索させるにはcom.apple.*を勝手に使うしかない。
しかしそれは勝手に使っていてたまたま動作するだけであって、実際はAppleのサポート外。
だから彼はそういうものを使うことにためらいを感じる、っていうことで、
com.appleを使うな、とはどこにも言ってないんじゃないかな。読み落としてたらすまんけど。
com.apple.*を使うのはサポート外であることを明示して、使いたくない開発者が使わないという選択をできるようにすべき、
っていうのが彼が言ってることだよね。

複数の開発者をまきこんだプロジェクトにしようとしてるんだから
この指摘はすごく正しいんじゃないかな。

ちょっと議論がかみあってなくて長くなってるけど、この案でいけるなら良かったね。

>>56
>だから彼はそういうものを使うことにためらいを感じる、っていうことで、
>com.appleを使うな、とはどこにも言ってないんじゃないかな。読み落としてたらすまんけど。

それはその通り。

ただ、最初の方の彼の発言は、問題を提起するだけで、何をしたいのか全然分からない。
「secret apiを使ってない」という表現に噛み付いたり、「スタンダードに従え」という
原理原則を語って、具体的な対案を提示してなかったんだよね。「言いたい事は分かるけれど、
じゃ、具体的に何を提案しようとしているの？」というのが、途中まで全く見えなかった。
いろいろ質問していったら、だんだんと「両方にデータを書き込めば」という発言まで辿り着いた訳ですよ。

>com.apple.*を使うのはサポート外であることを明示して、使いたくない開発者が使わないという選択をできるようにすべき、
っていうのが彼が言ってることだよね。

．．．という点も、最後になって彼が辿り着いた場所だけれど、そうなると、２つの異なるメタデータ
プロジェクトが存在することになるのかも知れない。

「私たちは、com.apple.metadataにはデータを書き込まない。org.openmetaに書き込む」と選択したら、
spotlightは使えない。独自に、検索機構を開発しなければならなくなる。そこまで、OpenMeta projectに
組み込もうとする貢献者がどれだけいるか．．．．ワカラン。

Google Meta

Google Memeta

Google Memento Mori

>>57
いやまあここでこんなこと話してもあんまり意味が無いんだけども・・

Tsai氏は最初から
(a)だけ採用して(b)は採用しない(なぜならそれはAppleのサポート外だから)
という選択もできるようにすべきだ、ってことを言ってると思うんだけどね。

> Some users like to live on the edge, and that's fine.

とも言ってるし。やりたい人がやることについては何も問題ないってことでしょ。
ただそれ(サポート外の動作に依存すること)を強要するのはどうかってことで。

そのへんが残念ながらうまく伝わらないで、
否定的な指摘をしていると思ってしまった人達が過剰反応した、って感じ。

>>61
>>>57
>いやまあここでこんなこと話してもあんまり意味が無いんだけども・・

お互い様だけどさ、

>Tsai氏は最初から
>(a)だけ採用して(b)は採用しない(なぜならそれはAppleのサポート外だから)
>という選択もできるようにすべきだ、ってことを言ってると思うんだけどね。

それが、具体的にいかなる変更を指し示すのか、最初は定かでなかったという事。

具体的でないから、「Perhaps there should be a way for such users to get (a)
independently of (b)」が、最終的に「とりあえず、com.apple.metadaの内容をorg.openmeta
にも同期させて、後者を使いたいユーザー向けに、新たに検索機構を設けたら？」という
内容であるなんて、理解できなかったの。

おそらく、彼自身も、最初は自分の言いたいことが、そうした具体案に行き着くとは
思ってなかったと思うよ。話をしていく間に、彼の口から、やっとその具体案が出て来た。

概念的なレベルの提案も、具体的に作業可能なレベルの提案に落とされないと意味ない。
それが出来たことが、あの議論の存在意義。

>>57
> 最後になって彼が辿り着いた場所

て書いてるけどそれはTsai氏が一番最初に書いてることだよ。。?

彼の一番最初の発言に対してOpenMeta支持者は
「そうだね、com.appleはたしかに問題がある。じゃあどうやる?」って聞けばいいだけなのに
何もsecretなものなんかないぜ、と反応しちゃったり(Tsai氏の指摘を誤解してる)
楽観・悲観論に持っていったり、「じゃあ検索エンジン作るのか?」
みたいな議論になっちゃってる。彼が一番最初から提案してるのはタグ共有と
検索を分けようってことだから、検索エンジンなんか関係ないと思うけども。

hoge氏はまあしょうがないとして、Jimっていうのはこのプロジェクトの中の人なのかな?
中の人がこういう態度とか認識ってのはちょっと残念な感じ。

>>27 です。

>>50
>>>23です。ironicの中の人と、いろいろ話してみました。

お疲れさまでした。スレ読ませてもらいました。

>印象では、ironicの中の連中はかっちりとしたプランを持ってない感じ。
>「何でも出来るから、みんな、google codeで意見を出し合って議論しよう」という状態だね。

hoge さんの粘り強い提案でしたが、見解のすれ違いで終わってしまったように見えました。
「属性の膨張(inflation of attributes)」という問題の深さは、開発を主導している当事者達にとって
分かりづらいものなのでしょう。過去に似たケースを経験したことがあります。
あるいは、彼が主張した現状の属性仕様に対し必要に応じて属性を追加していくという
(いきあたりばったりな？)アプローチでも、OpenMetaプロジェクトでは成功するのかもしれません。

>一応、>>27が後半に書いたような話をしておきました。ただ、この意見はironicのforumに出すより、
>google codeにissueとして挙げた方が確実だと思う。良かったら提案してみて下さい。

hoge さんが何度も Dublin Core というキーワードを送っていましたが無反応でしたね。
彼がこれを知らないとは思えないので、おそらくトップダウン的アプローチを
意識的に避けているのでしょう。したがって、単に issue として挙げただけでは黙殺されます。
具体的な問題点が誰にも分かるモノがない限り。提案は考えさせてください。

最後に、自分は英語はなんとか読めますが、フォーラムへ書き込むほど英文作成が得意ではありません。
だから、今回のスレにあった hoge さんの流暢で粘り強いを夢中で読ませてもらいました。すごいです。

うーん、別に個人的な感覚なんだけど、
DCってRDFみたいなので使うにはもってこいだけど、xattrにはちょっと合わないんじゃないかな…

hoge氏とBLUEFROG(Jim)はなんか議論からずれてるなあ。。
でもTom Andersenはさすがによく理解してる感じでちょっと安心した。

BLUEFROGってIronicのフォーラムの中で一番重要な人物なはずなんだけどなあ…

しかし、どうしてこう「ずれる／理解してない」事を、ネガティブに捉えるのかなぁ。

>>63
>彼の一番最初の発言に対してOpenMeta支持者は
>「そうだね、com.appleはたしかに問題がある。じゃあどうやる?」って聞けばいいだけなのに

そうだよ。誰もそれを聞いてないと見えたから、「どうやるって言いたいの？」と、聞いたの。

あなたは、Michaelの言う事が、最初から全部理解できた人かもしれないけど、そうでない人もいる。
そんなの当たり前の話でしょ？分からない人もいるから、人間は、言葉を使ってやり取りをせざるを得ない。
分かっている人には、どれほど無意味なやり取りに見えても。

>hoge氏とBLUEFROG(Jim)はなんか議論からずれてるなあ。。

もちろん。素人だもの。もし、Michaelが「こんな素人、相手にする価値がない」と思ったら、
返事もしてくれなかったと思うよ。

>>64
> Dublin Core というキーワードを送っていましたが無反応でしたね。

別のスレッドでJim自身がそれについて言及していたから、知っているとは思いますよ。
やっぱり、「トップダウン的アプローチを意識的に避けている」のでしょうね。
それも、一つの方法だし。

>「属性の膨張(inflation of attributes)」という問題の深さは、開発を主導している当事者達にとって
分かりづらいものなのでしょう。

あるいは、関係者の数が増えるほど意思統一が難しくなるという現象を軽くみているのか。
まぁそれも、実際に問題が起きたらその都度、やり方を変えて行くのかもしれないですね。

会話は悪くないさもちろん。
ただ攻撃されてないのに攻撃されたかのように感じて
過剰防衛するような感じになってるね、って書いただけだよ。
話のポイントずれると大事なところがちゃんと議論されなくなる可能性はあるけどね。

外から来たTsai氏が非常に重要な指摘を最初からはっきり書いてるのに
それをOpenMeta支持者たちが悪意のように理解してしまってるのが残念だと思ったので
中の人もちょっとしっかりしてくれよって思っただけ。

>>70

>ただ攻撃されてないのに攻撃されたかのように感じて
>過剰防衛するような感じになってるね、って書いただけだよ。

ホント言うと、そう思ったから、最初は傍観してて途中から「じゃ、具体的にはどうしろと提案してるんですか？」と
聞いたんだけどね。まぁ、聖人君子ばかりじゃないしなぁ、世の中。


しかし、Tom、早速メタデータのバックアップ機能を追加したらしい。
「これで何か文句あっか」と言ってるような感じだけど、結果的には
（Michaelが提案した方法ではないけれど）よりセキュアになったのだから、良かった、良かった。

http://code.google.com/p/openmeta/source/browse/trunk/openmeta/trunk/OpenMetaBackup.m?spec=svn6&r=6

>>71
お、アップデートされてたんだ。気づかなかった、サンクス。
もう少しで古いコード使ってビルドしたやつを公開するとこだったわ

Tsai氏のHackっていう書き出しのせいでああいう流れになったってのはあるね。
彼はあいまいにしたくなかったからはっきり書いたってことだけど。

しかしこのbackupのしくみとか、どう実現するか全く議論無しに
tomが書いちゃったんだよね。もちろんこれを誰かがまた書き換えたって
かまわないわけだけど、もうちょっと思慮深い開発者をちゃんとまきこんだ
仕様の議論があってもいいような気がするなあ。
こういうやり方で他の開発者がついてくるのか不安。

>>73
しかし、OpenMetaBackup.mの日付、1/26になってるんだよなぁ。Tom、ツンデレ？

>このbackupのしくみとか、どう実現するか全く議論無しに
>tomが書いちゃったんだよね。

google codeに書いてあるじゃない。当面は、全ての変更はTomがおこなうって。
そもそも最初のコードだって、Ironicだけで書き上げたんだから。

だんだん分かって来たけど、あなたやMichaelに共通なのは
「可能な限り全ての不安要素を排除すべきだ」と言ったポリシーだと思う。
ミニマックス戦略みたいな行動原理かな。それはそれで良いんだけれど、
「人々が直感的に正しいと感じる、複数の行動原理の一つ」に過ぎない。

>>54にあるように、しっくり来るっていうのは、やっぱり価値観を共有しているからじゃないかな。

「別に、Tomに付いてくる人間がいなくたって良いじゃない。不安定なSCより
よっぽどマシで使える環境があるというだけで良いのだから。それ以上は、
出来れば御の字。できなくても今より悪くなる訳じゃない」という価値観だって
あるんだよ。

どちらが正しいという訳じゃない。これはもう、好みの問題だと言うしかない。

> あなたやMichaelに共通なのは「可能な限り全ての不安要素を排除すべきだ」と言ったポリシーだと思う。

俺はそんなこと言ってないし、Tsai氏も言ってないと思うよ。
君(hogeさん?)はそういう風に思い込んで対立の構図を作るからずれるんじゃないかな。

サポート外のものを使いたくない開発者は使わなくてすむようにすべき、と
Tsai氏は言ってて、俺もそれはもっともだと思う。
あとサポート外の動作に依存しているってことをはっきり明示してないのは問題、
ってこともその通りだと思う。

どっちも不安要素を排除すべき、と言ってるんじゃないよ。この違いわかる?
これをごっちゃにしてるからあのスレはややこしくなってるんだと思うよ。

gdgd思想論議したいならフォーラムでやってろよ
1スレ目の100未満でこんなんじゃ誰も寄り付かないぞ

>>75
>俺はそんなこと言ってないし

OpenMetaBackup.hに対するあなたの反応をみて、そう思ったの。

あぁ、ごめん。走りすぎた。この話はもうやめる。

76が正論

Quick Search Boxプラグイン出たけど、Quicksilver派なので容易に乗り換えできないなあ

メタデータやタギングについてのスレッドがないので、
ここで思想的なことも議論してくれるのは勉強になる。
英語が読めないのでフォーラムでの話題を紹介してくれるのも助かる。
本当は情報学板か図書館学板あたりにメタデータやタギングの
スレッドが存在するべきなのかもしれないけど（図書館学板というのは
存在しないけれども）。

思想って言っても上で話になってたのは
開発上のスタンスみたいなことだけどね。。

まあ今の時点ではそういう話くらいでしかもりあがらないとも言える。

こういう技術の標準化みたいな話に興味を示すタイプ:

1. その技術を真面目に使う（かもしれない）技術系の人
2. そういう話をヲチするのが好きな人

ま、大概の人はどちらのカテゴリにもはいってないということで、流れ的に厳しいのも
うなずける。

こういうのは単独のアプリが対応するだけじゃだめで、
対応アプリで囲まれるくらいの環境じゃないと有効に活用できないからね。
広まってくれるまでは便利とは言えないかな。

なのにGoogle Codeにあるコードを見るとIronicが本気ではないんじゃないかと思えてくる…

dolipoと同じ匂いがする　一部ではやたら盛り上がってるけど数ヶ月後には下火になってそうな感じが

>>84
(対応済み or 公開目前）
Freeware
http://s-take.blogspot.com/2009/01/quick-search-boxopenmetaqsbopenmeta.html
http://s-take.blogspot.com/2009/01/openmetaomwizard.html

Tags.app
http://gravityapps.com/tags/overview/

Bibdesk & Skim
http://dl.getdropbox.com/u/187565/Skim-notes-openmeta.png

Tag Folders
http://web.me.com/jonstovell/Tag_Folders/Support.html

(developerが検討中 or ~からの返事待ち）
Journler, Philip Dow (well, trying to get a hold of him - he keeps himself busy)
Things, Cultured Code: (waiting, I'm very hopeful since I'm a BIG fan of Things) 8^)
Nifty Box, Tim Scheffler: (has said he'd take a look)
Papers, Mekentosj: (is looking at it to see how it could be integrated)
Taskpaper, Hog Bay Software: (waiting)
Together, Reinvented Software: (waiting - some people have mentioned this nice app)
Devonthink/etc., Devon-Technologies: (waiting - another one many of ours Users have discussed)

http://ironicsoftware.com/community/comments.php?DiscussionID=620&page=1#Item_0

フォーラムの方にshgとして書き込みしたものです。
hogeさんの精力的な発言には頭が下がりますが、
ちょっと極論に走りすぎで議論をややこしくしているように思います。

まず、使いたい開発者がcom.appleを使うことには誰も反対してないのに
それを使わないことのデメリットを語っても意味がありません。
「使いたくない人がcom.appleを使わずにOpenMetaに参加できるようにすべき」
というのが議論の本質です。

BLUEFROG氏がGravityAppのことを出してるのも同じ点でポイントからずれてます。
使いたい開発者が使うことには誰も反対してないんです。

そこの誤解のせいで議論がこみいってしまってます。

もしよければこちらで少し話をしてそのへんの誤解を解けるといいのですがいかがですか?
そういうことはしたくないというのでしたらもちろんフォーラムのみでかまわないんですが。

shgさん、お疲れさまです。

時間がないので、後できちんと書きますが、要点のみ。

「com.apple.metadataを使うな」と言ってないのは、良く分かっています。
信じないと思いますが「org.openmetaにも情報をミラーリングした方が良いだろうな」とすら
考えています。

しかし、Michaelは、Ironicの連中を説得するのに、しょっぱなで失敗しました。
私が加わる春香以前から、「なんでorg.openmetaが必要なんだよ」という流れに
なってしまっていたのはお分かりでしょうか。Michaelのようなやり方では、
到底、Ironicの連中がorg.openmetaを採用するように至るとは思えません。

皆が望むゴールは、「OpenMetaが、より安全で拡張性の高い、多くの開発者を惹き付けるシステム」になることです。
極端な話、Michaelが怒って掲示板から立ち去っても、Ironicの連中がコードを書き換え、org.openmetaが導入されれば、
それで良いのです。しょっぱなでTomにあんな反応を取らせてしまう書き込みをした以上、Michaelがどれだけ正論を
言っても逆効果です。

一連の質問は、それを目指したものだとご理解下さい。なぜ、Michaelにズケズケ質問する事が、その目的に
近づく手段だと考えているのか、後で書きます。

メアド交換するなりして直接やり取りしたらいいんじゃね？

>>88
hogeさん以外でそこまでorg.openmetaの採用に反対している人がいるように見えません。
僕にはhogeさんだけが分かってないように見えています。
BLUEFROGも分かってないと思いますが、彼は自分であんまり考えてなくて
(なぜかMichaelが的だと思っているため)hogeさんが言ったことに同調してるだけのようです。
なので、hogeさんが分かっててそういう風に書いているというのを知り非常にショックです。
議論をしているのではなく、わざと分かってないふりをしてそれを説得してみろと言っているわけですね。

分かりました。僕はそういう非建設的な議論をする人と議論をするつもりになれないので
とりあえずこの議論からは降ります。非常に残念です。特にこれ以上の説明は不要です。

>>90
>hogeさん以外でそこまでorg.openmetaの採用に反対している人がいるように見えません。

そうですね。けれど、Tomは結局何をしました？org.openmetaを採用すると宣言する代わりに
backupを作っただけです。どうやって、現時点で、唯一のコードの変更に携わると（google codeで）
宣言した人間を、説得できますか？

>分かりました。僕はそういう非建設的な議論をする人と議論をするつもりになれないので
>とりあえずこの議論からは降ります。非常に残念です。

分かってもらえない人には分かってもらわなくて構いません。それが悪い事だとも思いませんし、
人間、その時点で自分が正しいと思った事をやる以外に、出来る事なんてありませんから。

>分かってもらえない人には分かってもらわなくて構いません。
このスレじゃなくて公式フォーラムでやれよと思いつつ、
ディスカッションの一つだと思ってとりあえず読んでいたのだが、
単なるチラシの裏だったとは。

>>92
Michaelが主張する方法、すなわち「これが最も正しい改善方法なのに、
なぜ理解できないのですか。反対しているのはhogeさんだけです」とshgさんが
主張する方法に、重大な欠陥がある事を、やっとMichaelに理解してもらえたようです。

「これが最も正しい方法だ。なぜあなたには分からないのだ」と声高に主張する人たちに、
自分の主張には欠陥があるのだと理解してもらうには時間がかかります。その過程を
チラシの裏と呼ぶのはあなたの自由です。

shgさん

返事はしていただかなくて結構ですが、やっと、これでMichaelの指摘した問題を
どうやってOpenMetaに反映させていくのか、Tomが意見表明をすべき順番がやって
きたはずです。今度こそ本当に、あなた達のような技術者が知恵を出すべき時だと思います。
私のスタイルが気に食わないのは重々承知ですが、私はただのエンドユーザーに過ぎません。
期待しています。

shgです。あなたのやってることに僕は何も言うことはないんだけど、
上でも指摘たようにあなたは不十分な理解のまま人の考えを決めつける傾向があるようなので
私に関する間違いだけ訂正します。

僕は一度も「これが最も正しい改善方法なのに、なぜ理解できないのですか。」
と言ったことはないよ。
またあなたのスタイルが気にくわないわけでもありません。
単に論点がずれぎみで理解に間違いがあると思っているだけ。

少なくとも他の人間の意見をサマライズするなら、
よく理解した上で書いて欲しいと思う。

駄目だこいつら
もうOpenMetaの末路は見えたな

shgさん
確かに「I think this is a practical and reasonable solution」と書いたはずのものを
記憶のみに基づいて、あたかも「this is the (best) practical and reasonable solution」とでも
書いたかのように記述したのは、筆の滑り過ぎです。すみません。

前にも書いたように、現時点におけるコード変更／変更承認をする唯一の人物、
Tomが、Michaelの指摘した問題を解決（ないしは、解決した内容をユーザーに報告）しない
限り、この問題はどうにもなりません。そのためには、正確な相互理解などは無視していました。
それがshgさんらを不愉快にさせたことは事実です。今さらですが、それは謝罪します。

OpenMetaタグを
特定のフォルダ内のファイルについて
iTunesみたいに管理できるアプリってありますか？

次のバージョンのLeapが一番近い。

ttp://www.ironicsoftware.com/leap/index.html

>>99
ありがとうございます。
触ってみますね。

任意のタグを自由に付けられるのかな？

ttp://s-take.blogspot.com/2009/02/for-openmetaomsavepanel.html

この人、仕事早いですね。これでDefault Folder Xを買わなくても済むかも。
一度入力したタグは、自動補完機能で選べるようですが、Tags.appの様に、
自動的にリアルタイムでタグ一覧をspotlightデータベースから収集して、
タグクラウドとして表示できるようになったら．．．高望みしすぎですね。
そうなったら他の商業ソフトが必要でなくなってしまうし。
ホント、素晴らしい。お疲れさまです。

とりあえず当面は一部だけで盛り上がるにすぎるんだろうなと思った

元来、タグ付けは万人が必要とする機能ではない。である以上、そんなにスレがのびる訳ないだろ。
>>102とか、そういうことやってて楽しい？

話は代わって、GravityのTags.app、version upがきた。
OpenMeta版Leapが出る前に出来るだけ多くの顧客を獲得しようとしているのか、
かなり動きが速い。

あと、Contextual Menuからタグ付けするプログラムを書いて公開している人がいる。
↓の下の方。
http://ironicsoftware.com/community/comments.php?DiscussionID=624&page=1#Item_0


SkimもOpenMetaを微妙にサポート（ファイルを新規保存するとxattrも継承して保存するようになった）。

という具合に、このスレが盛り上がるかどうかと関係なく、世の中は動いてるんだよ。

>>103
>>102の誤用には突っ込まない優しさw

OpenMetaまめ知識

原理的には、スペースを含んだ文字列もタグとして登録できる。
実際、Tags.app (by Gravity)では、問題なく入力できる。

しかしTagit.app (by Ironic)で入力中にスペースキーを押すと
区切り文字として見なされてしまうので、エディタかなにかで
"aaa bbb"と、ダブルクオーテーションでタグを囲んでから
Tagitの入力パネルにコピペしてやると、空白を含んだ文字列を
タグとして入力できる。

応用例：「"aaa bbb" "ccc ddd"」をコピペしてやれば、２つのタグを同時入力することも出来る。

タグ付けのし易さに影響する大事なポイントだけど、この辺りの使い勝手まで
アプリ間で統合する必要はないんだろうな．．．

光の速さで即レスするけど、
Tagitとかは_で区切るとスペースを含んだタグになります

ホントだ。アホですね、俺。

アプリって上書きでバージョンアップすることが多いと思うんだけど、
その場合タグの引き継がれることはないよね？

引き継がれないとまずいでしょ

引き継がれるわけないだろ。

Tagit使ってみたけど、ファイルについてるタグを表示するのに
いちいちDockのアイコンまでドラッグしないといけないのが
面倒くさい。Command+I でファイルの情報表示できるみたいに
ショートカットキーで簡単に表示できるようにならないんだろうか。

Tags.appがホットキー一発で呼び出せるけど、シェアウェア。

OpenMetaって、要はファイルにタグを付けられて、ファイルをタグで高速に探し出せる
ってことでいいでしょうか?

これって、もしかして昔の Mac OS にあった（今でもある?）機能のを再実現するのも視野に
入ってたりするのかな。ってゆうか入れられそうに見えるんだけど。

例えば、タグにユニークなIDを使えばそれでファイルが移動されても追随できそう。
タイプ/クリエータ的な情報を付けられそう。
（今ってアプリと書類の関連付けって主にどうしてるんだっけ? 拡張子? UTI ってのも
聞いたことがあるけど、あれって実際にはどこに情報を保存してるんだっけ?）

でもあれか、実際にはここら辺は Apple の中の人がやるべき領域か。

>>113
OpenMetaは検索目的のメタデータ（タグとかレートとか）と非検索目的のメタデータ（作業工程とか）を付けられる。

> 例えば、タグにユニークなIDを使えばそれでファイルが移動されても追随できそう。
> タイプ/クリエータ的な情報を付けられそう。
これは今のOSXにもあるよね。エイリアスがそうだし。
タイプ／クリエータ（シグネチャ）も今もある（だんだん使われなくなってきてるけど）。

UTIはファイルの拡張子やタイプから導かれるもの。

ネットの検索結果や、文章の解析などでタグを自動生成しようというものが有りますが、
自分のプライベートな領域は、どのようにして守るのでしょうか。

自分でつけるタグはせいぜい数種類だと思いますが、
自動生成したタグは一気に十数種類が可能だと思います。
すると、自分でタグの組み合わせをカスタマイズして作ったスマートフォルダなどは、
知らないうちに、入れたくない物が入り込んでしまわないですか？

また、セキュリティ問題も出てきませんか？
例えば、迷惑メールで、「diary」というタグの付いたファイルが勝手に送りつけられて、保存してしまうとか、、

>>115
ごめん意味が分からない

急に春めいたせいか？

>>115
あるねぇ。勝手に、kMDItemKeywordsの中身がspotlight コメントの中にコピーされた事とかあった。
確か、Togetherか何か使ってるときだったろうか。

この問題は、大抵、アプリ側の設定を変える事で対処できる。それがダメでも開発者に
文句付ければ、対応してくれるから、深く考え込む前に行動すればいいだけだよ。

話しがまとまってませんでしたか。

極端な例を出すと、

例えば、Spotlightで「tag:FF ムービー」という検索を行って、それをスマートフォルダとして保存したとします。
その中に、「FFのコスプレをした18禁ムービー」が入り込まないようにする方法はあるのか？
という事です。
結果を100％自分の管理下に置こうとすると、結局は、フォルダによる階層構造と同等か、それ以上の注意を払わなければならなくなりませんか？

そもそも、そういう使い方はしないものなのか？
フォルダ管理と併存する事はやむを得ない事なのでしょうか？
（例えば、先ほどの例で、FF ムービーというタグで集めた物を、DVDに焼いて友人に渡す、などという使い方は出来なくなるわけで。）

自分でつけるタグはせいぜい数種類だと思いますが、タグの自動生成では、一気に数十種類のタグがつけられる可能性があります。
セキュリティと言ったのは、そういうところとも関係してて、
例えば、スパム的に、悪意を持って、
「diary」「movie」「favorite」「private」「friends」などとつけられたファイルが知らない間に流れ込むようになったら、致命的になりませんか？

>>118
ソフトウェアの仕様による混乱は、それを把握出来ていれば問題なさそうですね。

＞深く考え込む前に行動すればいいだけだよ。

いろいろやってみます。

不用になったタグはどうやって削除するの？

OMwizardではダメだったっけ？

タグの置換が出来るから、空にして置換してみたけど消えなかったよ。

Desktop画像見せなさいスレで消し方見た気がする。

今試してみたらできたよ

MacHeistでFreshのキーを配ってる
でもバージョン1.x用らしい

>>125
? Fresh 出たばかりだから、バージョンは、1.0.0 だけど?

Tagit 1.1にしてから、画面右端のD&Dエリアがなくなって不便

>>127
drop zone を使いたければ、Fresh 使えってことだと思う。今ならMacHeistで貰える。

>>128
貰いました。
でもLeap&Deep&Yepセットを買ってしまいそう。あるいはTags
Tags一つで大体の用途は満たせると思うんだけど…

>>129
Tags は、Fresh あればいらないかなーと思うけど、
Leap & Deep & Yep はインターフェースが一体っていうのが
よさげだなと俺は思ってる。Heist か、Bundle Box でどれも
来なかったら買おうかと...OpenMeta対応版はいつかな。

>>126
つまり、バージョンが2.0になったら使えなくなるって事です
そんとき別の物探せば良いんだけど。

OpenMetaライブラリのコード(openmeta.m)を見ると、
拡張属性のデータ形式にkCFPropertyListBinaryFormat_v1_0を
使っています。Appleはそのデータ形式を公開していないので(？)、
OpenMetaはMacOSX限定でオープンな仕様であると思うのですが、
この認識は正しいでしょうか？

もしそうであれば、たとえばOpenOfficeでのOpenMeta対応は
Mac版だけでしか実現できません。Linux/Winでは実装不可能です。
まぁOSX向けの仕様であると定義されているんでしかたないんですけど。

あれ、Core Foundationからバイナリplist扱えなかったっけ

Core FoundationはMacOSXの一部ではないかと。
Core FoundationのLinux/Win移植版が存在するか、
あるいはソースが公開されていればいいんですけど。

いや、CFってソース公開されてるよ

失礼しました。CF-Liteというのがあるんですね。
http://developer.apple.com/opensource/cflite.html
これを使えば、少なくともLinuxへは実装可能な感じ。

おお、そっちで来たか。
Core Foundationそのもののソースが公開されてるからそれでバイナリの仕様を調べれば、って意味だったんだけど。

>>27 です。

hoge さん、このスレまだ見てますか？

>>64 で書いた提案の件ですが、検討に着手しています。
最終的な成果物として「具体的な問題点が誰にも分かるモノ」を目標にしています。
とりあえず現時点での出力を以下の場所にアップしました。

http://www.h6.dion.ne.jp/~machan/

現状は Spotlight(CoreService.Metadata) 関連の仕様を整理したものでしかありません。
今後は、肝心なOpenMeta/Spotlight/Dublin Core等の各メタデータスキーマ間における
属性の対応付けを調査/検討し、出力に反映させていく予定です。
それら作業が完了して、ようやく具体的な提案の検討に着手できます。

>>all
他に独自の Spotlight Importer を持つアプリがあれば、挙げてください。
アプリのパッケージ(バンドル)から自動的に文書を出力する仕掛けにしているので、
フリーソフトあるいは商用ソフトでも試用版がダウンロード可能であれば追加できます。

協力できる学はありませんが注目して見ています
メタデータに興味があるので

階層的管理→タグ管理という管理方法のシフトの意義は
階層的フォルダみたいなグローバルな構造を意識せずに
個々のファイルにのみ注目したタグ付けを使うことにあると思う。

ユーザベースのタグ付けにDublin Coreみたいなものを持ち込むと
"Dublin Core"というグローバルなしばりを意識しないといけなくなるわけで
恩恵の多くを失うと思うよ。

Dublin Coreがターゲットとしているのはこういうアプリケーションじゃないと思う。

>>138
激しく乙

>>140
いや、問題にしてるのは個々のタグ付けのネーミングルールじゃないんじゃね？

>>140

いくつか誤解されているように思えます。

まず最初に、ユーザが自由にタグ付けできるメタデータ属性(kOMUserTags)については、
そのまま残すつもりです。この情報に対して制約を加える気は一切ありません。

>ユーザベースのタグ付けにDublin Coreみたいなものを持ち込むと
>"Dublin Core"というグローバルなしばりを意識しないといけなくなるわけで
>恩恵の多くを失うと思うよ。

OpenMeta には「ユーザによる自由なタグ付け」および
「アプリケーション間での緩やかなデータ共有」という二つの意義があると思います。
前者については、先にも書いたように「しばり(制約)」を加えるべきではないでしょう。

しかし、後者については何らかの「しばり(制約/規約/約束事)」が必要であると考えています。
たとえば (>>20 で書いたように)人名に限っても同じ主題(人物)に対して複数のメタデータ属性を
対応付けることができます。それらをアプリケーションのデベロッパが自由に(何の制約も無しに)
割り当てていった場合、最終的に不便を強いられるのはユーザです。

現状でも(>>138 で公開した文書を見れば明らかなように) Spotlight なら kMDItemXXXX、
OpenMeta ならば kOMXXXX というメタデータ属性に関する規約(しばり)が存在しているのは
理解していただけると思います。

そして、この検討で課題としているのは(>>64 で書いた)「属性の膨張」であり、
その解決手段が(>>141 氏が指摘している)メタデータ属性に関する(ネーミング等の)規則です。

>Dublin Coreがターゲットとしているのはこういうアプリケーションじゃないと思う。

Dublin Core は「メタデータの仕様」なく「メタデータで利用される語彙(ボキャブラリ)の仕様」です。
言い換えると、ある特定のアプリケーション(応用分野)に特化した(...をターゲットとした)仕様ではなく、
あらゆるアプリケーションで共通な語彙を最小限の範囲で規定したものでしかありません。

(>>142 への追記)

>そして、この検討で課題としているのは(>>64 で書いた)「属性の膨張」であり、
>その解決手段が(>>141 氏が指摘している)メタデータ属性に関する(ネーミング等の)規則です。

この規則の適用対象は(しばられるのは)OpenMeta対応アプリを開発しようとするデベロッパです。
決して(アプリを利用する)ユーザをしばるものではないので、誤解されないよう。

ていうかOpenMetaじゃIRI名前空間が使えないからDublin Coreは使えないでしょ。
QURIEっぽくすればできなくもないけど無理矢理過ぎる。

>>138 の文書を更新しました。主な変更点は以下のとおりです。

* 複数ページに分割した(文書形式を DocBook へ移行)
* OpenMeta インポータを更新
* 以下のアプリケーションインポータを新規に追加
　　Booxter/SOHO Notes/Curio/Dossier/Nifty Box/Mori/
　　OmniGraffle/OmniFocus/OmniOutliner/OmniPlan/
　　Papers/ReceiptWallet/Punakea/Tags/Yojimbo

文書の場所(URL)は >>138 と同じです。
一括ダウンロードするには、以下の URL を指定してください。

http://www.h6.dion.ne.jp/~machan/mdimref-0.2.tar.gz

hogeです。これは、次のような試みだと考えれば良いのでしょうか？

「OpenMetaによって、メタデータの利用可能性が一気に開けた。
しかし、OpenMetaによるメタデータ管理は、メタデータ属性の
インフレーションを引き起こすかもしれない。その問題を懸念した
ユーザーが、現在、Spotlight(CoreService.Metadata)で利用されている
メタデータの一覧／レファレンスを作成した。これはAppleだけでなく
サードパーティーが開発したmdimporterで定義されているメタデータも
含まれている。メタデータを利用しようとする開発者が、これを参照することで、
似たようなメタデータ属性が溢れ返らないことの一助となれば幸いである。」

．．みたいな感じ？これはこれで、便利だと思う開発者はいるんじゃないかと思います。

もし、IronicのOpenMetaフォーラムに挙げてほしいという事でしたら、
代行します。google codeにissueか何かで挙げる場合には、138さんが
やられた方が良いかと。

どうしますか？

>>138 です。

>．．みたいな感じ？

付け加える事は何もありません。的確な解釈です。

>どうしますか？

この文書が OpenMeta 普及に何かしら役立つのなら、こんな嬉しいことはありません。
Ironic フォーラムへの対応は hoge さんに一任しますので、よろしくお願いします。

>google codeにissueか何かで挙げる場合には、138さんが
>やられた方が良いかと。

はい、そうします。ただ、今は下準備(基礎固め)の段階であり、最終的な提案(具体的なモノ)は
白紙の状態で、完成は当分先になります。ですから、その時にまた考えればよいと思っています。

138さん

投稿しておきました。「コメントがあったらこのスレに書いておいて。Machanが見に来るから」と書いておきました。
http://ironicsoftware.com/community/comments.php?DiscussionID=747&page=1#Item_1

138さんの名前、Machanということにしておきましたが、嫌／間違いだったら書き直しておきます。

投稿ありがとうございました。

>138さんの名前、Machanということにしておきましたが、嫌／間違いだったら書き直しておきます。

Ironic フォーラム内でのハンドルネームなので、そのままでかまいません。

フォーラムを見に行くと、さっそく Tom からコメントがありました。
できる限り OpenMeta の属性は増やしたくないという彼の意思も理解できます。
でも、現実に(Ironic が想定していなかった)他のアプリケーションのデベロッパにとっては、
既存の OpenMeta 定義に当てはめることができない属性は存在していると考えます。
ですから、ユーザの立場で、デベロッパ達が混乱せずに OpenMeta 対応アプリケーションが
続々と登場することへの期待をコメントへの返事として書きました。
中学生のような下手な英語なので、理解してもらえるかどうかは分かりませんが。

とんでもない。大丈夫です。相手がネイティブなら絶対に通じる。

英語の細部に文句付けてくる嫌らしい連中ってのは、大抵、
ネイティブでない、海外にいるという事ぐらいには自慢できるものを
持たない人間です。

あのレベルなら絶対に大丈夫。もし、相手に自分の言ってる事が伝わってないと
思ったら、「それは違う。こうなんだ」と繰り返せば良いだけです。

大抵の場合、ネイティブがこちらの言う事を理解できないのは、
こちらの英語がマズいのでなく、そもそも内容が理解できない事の方が
多いです。「お前の言ってる事は分からない」と言われても、絶対に
ショックを受けない方が良いです。相手の頭のレベルが、こちらの頭のレベルに
追いついてないケースの方が遥かに多いですから。

専門家同士の対話ならば、最後の手段として、（今回のreferenceのような）
現物を見せてやれば、それで一発で通じます。互いに知識を共有した専門家同士の
会話ほど、容易なものはありません。

ちょっとチラシの裏になりすぎましたが、頑張って下さい。

Ironic フォーラムへの書き込みは、今後もできるだけやってみます。

Jim は膨張問題のとっかかりに気づいてくれたようだし、
とりあえず文書そのものは二人に喜んでもらえたようなので、
自分としては満足しています。

QuicksilverとTagitを組み合わせて使っている人っていますか？
TagitがDockへのドラッグ&ドロップなら複数ファイルを認識してくれるのに、
QuicksilverのTrigger経由だと認識してくれなくて困ってます。
他のソフトなら認識してるからTagit固有の問題だと思うんですが…
Quicksilverに拘るつもりは無いので、TagsみたいなHotkeyでのをタグ付けを
フリーウェアだけでやれる方法を知ってる方いたら教えて下さい。
キーボード派は皆Tags使ってるんでしょうか…

>>152
Finderのスクリプトフォルダにこんなのを入れてる。

tell application "Finder"
open selection using (application file "Tagit.app" in folder "Applications" in startup disk)
end tell

>>153 つづき
ホットキーは Quickeys で設定してます。

そのスクリプトをQuicksilverに登録したらいけました。ありがとうございました。

Tags.appの評価期限が切れたので、消そうとしたがアンインスコできねえww

Tags 1.2age

静かになっちゃったね。

アンインスコできた・・・てか勘違いだった
オ〜プンメタage

ところで、今まで付けてきたSpotlightのタグをOpenMetaタグに変換してくれるツールとか、ないの?

どっかにありそう

>>161
見つけた。
Tagsで出来る。
File -> Import Tags
これで、フォルダ指定してその中のSpotlightタグをOpenMetaに変換してくれる。

となると、今度は逆が欲しいw

>>160
他に
http://ironicsoftware.com/community/comments.php?DiscussionID=823
っていうのがあった。

情報整理スレで「NAS上のファイルにタグが付けられないぞゴルァ」とわめいてたものですが。

思い付きでやってみました。
1.ローカルにファイルを作る
2.FreshでOpenMetaタグ付け
3.NASへコピー
4.Freshでコピー先のファイルを確認 -> タグを読めない
5.コピー先のファイルをローカルに再びコピー
6.FreshでNASからコピーしてきたファイルを確認 -> タグを読める

ということで、OpenMetaタグ自体(xattr)は、
ネットワーク上のファイルにも存在することが解りました。

Spotlightで検索対象に出来ないのは、理解が出来るのですが、
OpenMetaタグに対応しているアプリで、
タグそのものを読み出したり書き換えたりできないのが納得できません。

誰か、なんとかして下さい...
ひょっとして、Mac OS X自体が、ネットワーク上のファイルのxattrを読み書きできない?

>>164
OM対応アプリ作ってる身だけど、
ファイルからOMメタデータを読み出すのには大体MDItemやNSMetadataItemを使ってて、
getxattrはあまり使ってないから、結果的にSpotlightの及ばない所でOMを扱えない事が多い。

>>165
そうなんですか。
でも、Spotlightは、初期状態ではネットワーク上のファイルを「読みに行かない」だけで、
「読めない」訳では無いんですよ。

mdutilでNASへの検索を有効化して、
NAS上に適当なテキスト・ファイルを作って、その内容を検索すれば、
しっかりとピックアップしてくれます。
iTunesのコメント欄で記入した内容も、検索対象になっています。
(Spotlightコメントは、NASに置いたファイルに直接書き込んだものは対象とせず、
ローカルで書き込んだものをコピーした場合は、検索対象になるようです)

が、OpenMetaタグを記入したファイルをNAS上にコピーしても、
それらを検索対象にはしてくれません。

この差がなんなのか、僕にはよく分からないのですが、
ネットワーク上のファイルに、OpenMetaタグを書き込むことも読み込むことも出来ないのは、
Mac OS Xに置けるxattrの取り扱いの制限なのか、
それともOpenMetaのインポータの不備なのか、というのが疑問です。

http://journal.mycom.co.jp/column/osx/134/index.html

Tag Foldersというのが出ていた。
ttp://web.me.com/jonstovell/Tag_Folders/Tag_Folders_Home.html

PunakeaもOpenMeta 対応したよ〜

MacUpdate PromoでTagsが45% offだね。