とっぷぺーじ
ねこめしにっき
2003/06/中旬
2003/07/上旬
ダバディたんは当然トルシエ寄りだろから、カワブーチには私怨がありそうだけど（笑）、それはさておき。
チーム力の８割は選手個人の能力とマッチメークを軸とした協会の方針で決まります。監督の仕事（練習や戦術）は残り２割。試合前に選手たちを調和させ、刺激を与えることぐらいです。中村のように若い選手がどれだけ成長できるか。協会がいかにいい方向性を示せるかの方がはるかに重要なのです。
今や、アーセナルやレアルマドリードといった名だたる欧州ビッグクラブへ出身監督を 2 人も送り込んだ名古屋ぐらんぱす（←物は言い様（大ワラ））だけど、彼らが監督してた「ぐらはち最良の時代」もやっぱり優勝はできなかったわけだし、今でもうだつのあがらないチームのまんま。やっぱり協会
…というかこのバヤイはフロントだが、強化への明確なビジョンが無い事がいちばん効いてるんだよな。 J でも強いクラブはフロントがそれなりに明確な強化ビジョンを持ってるとこばかりだし。
サッカー自体はトルシエ時代とは違います。自由なチームになりました。トルシエ監督のチームは組織を何よりも尊重する選手が８割、個人能力の高い選手が２割でした。今はそれが逆転。どちらが正しいということは言えません。それは監督の哲学の問題です。ただ私は今の日本には組織力に基づいたチームの方が合っていると思います。せめて８割の選手が海外リーグで活躍する時代にならなければ自由主義は難しいでしょう。
ベンゲルがグラハチを指揮してた 8 年前にも似たような事を言ってたやね。
日本人が常に厳格で、明確に定義された任務を求めているということに気づくまで、時間がかかってしまったのだ。私は選手たちにもっと自立した、自由な表現を求めていた。
私に言わせれば、ボールを支配するのは、ボールを持っている選手であるべきなのだ。ボールを持っている選手は、その時点で一番よいと思われる方法を選ぶべきなのだ。だが選手たちは、それをゲームのシチュエーションのなかで学ぶより前に、まず私が適切と思う方法を教えることを期待していた。私が選手に期待していることと、私が選手に求めることは、ちょうど正反対だった。
（略）そのことに気づいた私は、選手が自己表現をしたいという意欲をそがないようにし、それでもできるだけ細かく、具体的な指示を出すように努めることにした。（略）時間をかけて、日本人の性格にあった方法をとっていけば、自己表現の能力を伸ばしながらも、それぞれが限定された役割を持ちたいという、彼らの意思も尊重していくことができるかもしれない。
8 年後の今でも状況はそう大差ない感じ。トルシエの方針も、だいたいこのとおりだった感じ。ダバディがいうように、中田や俊輔や小野ちんのようにプレーで自由な表現
を出せる選手がもっと増えるまでは、任務遂行型じゃないとうまくいかんと思われ。とはいえいつまでも任務遂行型では進歩の限界が来るのが目に見えてるという観点で、「自由表現信奉者」なジーコを監督にすえて、急激にパラダイムシフトしてやろうと目論んでみたと言えるカモ。監督の選定にそういう真っ当な意図があったノダという、ものすげー超絶好意的解釈をすればだがー（w
しかししかし、代表チームとゆーピラミッドの上辺だけそんな意識改革をしようなんていっても、そんなんどだいムリにきまっとるがな。年少のみぎりから部活や J クラブに至るまで、任務遂行サカを骨の髄まで刷り込む指導をされてきた方が圧倒的に多いだろうし。それ以前に、「自由表現型」が日本人にとって、ホントにモノになるものなのか自体謎。明確に定義された任務
でほぼ全ての要素が構成されてる野球のほうが、圧倒的に人気があるという、一朝一夕には変わらない国民性もあるし。
ナカータが口酸っぱく言ってた「コミュニケーション」てやつは、任務遂行型なら不要なのよね。黙々と各自の限定された役割
をこなしてればいいのだから。任務遂行サカに慣れた選手達がコミュニケーションを苦手とするのも、むべなるかなという感。で、ナカータはブチギレすると。わらい。
とか知った風な事を書いてる自分だってやっぱり「明確に定義された任務
を忠実にこなす」事のほうが得意な、典型日本人なのであった。あーあ。なにがわるいんだ。きょういくがわるいんだ。（ぼうよみ
「任務遂行型サカ (2)」に続く。
FOAF の <foaf:mbox_sha1sum> 要素で使う事でおなじみの sha1sum 。ほうぼうで提示されたいろんな計算方法のまとめが 適宜覚書 (2003/06/28)
に。
というか，FreeBSDにはsha1sumなんて(入れないと)無いし……．
echo -n "foo@example.com" | openssl dgst -sha1ならシステム標準かなあ(笑)．
[ SHA1 - HoLY Dialy (2003/06/29) より ]
OSX でもコレで行けますた。ちうか echo -n "foo@example.com" | openssl sha1 でも良かったり。
openssl で計算できそうなのは気づいてて試してたのだけど、なんか計算結果が違うナーと思ってて。よく考えたら echo の -n オプションを付け忘れて、改行文字も含めた計算をさせてたオチ。ださっ。
FOAF の <foaf:mbox_sha1sum> 用途の時は、メアドに mailto: をつけなきゃいかんのをお忘れ無く。
<foaf:mbox> は URI としてメアドを指定するものだし、その sha1sum 値をリテラルとして書くのが <foaf:mbox_sha1sum> なのでして。
XTを使ってXSLT変換すると、半角スペースが消えてしまうのですが……。
何度やっても
<meta hoge="hoge"/>になってしまう……。
半角スペース
ってのは、XML の空要素閉じタグ短縮記法 <hoge /> の hoge と /> の間の空白のことかな。
XHTML においてそこに空白を入れとく事が要請される場面ってのは、旧来の HTML しか解釈できないブラウザ、あるいは XHTML を HTML として処理してるブラウザにて、 XML である XHTML を HTML としてムリクソ解釈させたい時ぐらいなものでありまして。 XSLT つのはキホン的には、ある構造の XML をまた別の構造を持った XML へ変換するシロモノなんで、 XHTML にまつわるそのへんの後方互換な思慮なんかシラネーヨって感じの扱いを受けても、致し方ない部分ではあるです。
同様に、空要素タグでなくとも内容がカラのときに短縮記法 OK なのが XML だけど、後方互換を考慮した XHTML 的には都合が悪いケースってのは他にもあって。たとえば script 要素。元 XML 中や XSL の中でいくら <script src="hoge.js"></script> と書こうが、 <script src="hoge.js"/> と出力されがち。ほとんどのブラウザは、こういう記述では hoge.js を読み込んではくれなくなるわけで。
んで、他、ツッコミというか補足語りというか。
ねこめしにっきヘッドライン<xsl:preserve-space> は、 elements 属性に指定した要素の内容に含まれる空白文字類を保持するかどうか指定するものでありまして。出力 XML のタグ内の空白をどうするかとは無関係であります。大ざっぱに言い切っちゃえば、ソース XML の該当要素に xml:space="preserve" が指定されていたものとして扱う、みたいな、そんかんじ。<xsl:text> も、大ざっぱに言っちゃえばベタテキストを書くだけのシロモノなんで、要素を含ませることはモチロン出来ないのであります（もちっとマシな言い方をすれば、テキストノードを生成するための要素、というか）。 XSLT のテンプレ中に HTML の要素をフツーに書いた場合は、出力 XML のノードツリーへ「 DOM 的に」生成追加される（から XSLT プロセッサの要素生成ポリシーの影響を受ける）のに対して、 DAC さん例示の <xsl:text disable-output-escaping="yes"> で HTML 要素を「書く」やり方は、JavaScript を例にすごい強引なたとえすると、 document.write() でタグを「書く」事に相似してる。「タグを書く」のはできればやりたくない事なんだけど、今回の件とか他にもいろんな事情でやむを得ない時がありますやね。Xalan-Java だと、空要素の /> の前には半角空白を入れといてくれるんで、ぼくはその点は助かっとります。でも要素内容がカラな時に常に短縮記法で出力される件や、そのほか困った事になる場面で、「タグを書く」等の場当たり的対処をイロイロしてる次第で…。内容がテキストだけでなく要素も含んでる pre の空白文字の扱いとか、あれとか、これとか。
このへんのネタは以前そふぃあさんが語っていた記憶があるのだけど、記事が見つからないー。
「空白文字類の扱われかた (2)」に続報アリ。
これがいわゆる「アーチスト様気取り」ってやつですか？
どっかの北欧のデスメタバンドとかだと、メンバー全員でバトルロイヤルの挙げ句解散とか。殺人で収監とか。日常茶飯事で（←言い過ぎ）。アーチスト様ならそのくらいやっとけ。（ぉ
(´-`).。oO（めちゃ長いつけ毛？とフリヒラ衣装のるちあたんが鬼萌えだったヨ…まいったな…）
(´-`).。oO（ミルモでポンは作画が神の領域だったヨ…まいったな…）
MacOSX 用の独自ビルド版 Firebird 20030615 に入れたッス。要望をたれてみるッス。
というか何というか、MacIE のページホルダーそのものがホスィって言ってませんか、コレ。でも実際あれは、コロンブスの卵的ナイスアイデアだったヨ。ただ単に好きなページを即座に放り込んでハイオシマイ、あとは好きにしやがれ、使い方は特に強制しないからさ、みたいな。枝葉機能と割り切ってて、枝葉なりの工夫もいろいろしてるくせに、それをこれ見よがしにしない、出しゃばらない清い感じがよかった。 MacIE て、ホントに Microsoft 的じゃなかった。
「RSS の description の自然言語要約を AppleScript に任せた」でこの一連の手順をシェルスクリプトに書いて cron で駆動
とか勇ましく書いたものの、問題発生。 osascript コマンドを含むシェルスクリプトを普通に Terminal 上で実行する時は無問題なのに、 cron で定期実行してみるとなぜかファイルサイズがゼロな rss.rdf が出来やがるオチ。
XSLT 変換をしてる AppleScript も、それを発動させてるシェルスクリプトも、正常に動作してるフーなのだけど、謎。標準エラー出力にも何も出ないしワケワカ。なんか環境変数とかソッチ系の問題のような気がするのだけど、どーにもわからんちん。
なので仕方なく、 RSS （と日記トップページのヘッドライン欄）はもう、手動で更新をかけることにした。それ用のスクリプトも用意したし、手間はそれを発動させるために mi でキーを一つ押す操作のみ。かねてより、 RSS の更新を 6 時間ごとの自動更新にしてるのはどーなのよ、とも思っていたので丁度いいカモ。
最新の日記の更新と連動して RSS の更新をかけるようにするのが、次の課題かなぁー。
なんぞが完成したからと安心して、些細なトコをちょこっといじって、確認しないで放置して、そのちょこっとの変更がじつは致命的凡ミスだったり、寝不足はいかんなーまったく。
ウチの RSS の item の description
（項目の説明文あるいは要約）も、日記記事内容を単に丸ごと引き写して、んで単に先頭から 165 文字のところで切り落としてただけ。それだとちょっと要約としての妥当性というか、情報価値がイマイチだというのは、以前「RSS の description の要約の妥当性」でぼくも感じてた。上記リンク先のやりとりで、この件を放置してた事をハッと思い出した次第。
岩井さんがやってるように、日記本文と別に description の内容も手動で書くのがいちばん確実なのだろうけど、やっぱりめんどくさいというか何というか。 Mac には OS8.5 のイニシエから、 V-TWIN なる言語解析エンジンが搭載されてて、その一部として自然言語を上手に要約する機能があるわけで、これを利用できたらいいなと思ってヤった事が今回のネタ。
前回のにっきでは、 OSX の SummaryService とゆーアプリ形式の service をどうにか利用できないか、とか書いていたわけだけど、よーく考えてみたら、その service は OSX からの新顔に過ぎなくて、 OS8.5 のみぎりから AppleScript には
summarize
なる語彙が Standard Additions にあったことを、今ごろ思い出した。とゆーか完全に忘却してた（笑）
てなわけで、この日記の RSS の各項目の description を、この要約作成 AppleScript 経由で作成するようにしてみたですよ。どうかな。結構なかなかの要約精度…というか核心をついた一文が抽出されてると思う。すげぇすげぇ。アポーすげぇ！ AppleScript マンセー！
ただ、要約文の文字数をキッカリ指定することはできないから、抽出された一文がすごく長くなる時もあるわけで、さらに一定の文字数でぶった切るようにしてるです。まぁこれでいいでしょ。
今日からの RSS 作成処理の流れを記しておくとします。
description はまだ要約されてなくて、ただ日記内容を引き写しただけ。description 要素の内容を要約したり一定文字数での切り落としをしたりしつつ、 XSLT 変換する。osascript scriptfile
とかすればいいです。今回初めて XSLT Tools OSAX を使ってみたのだけど、なんだこれ。速いぞ！ 内蔵してる XSLT プロセッサは Xalan-C なんだけど、 Xalan-Java より 5 倍は速く変換処理するぞ…。うわー。これからは全部コレで XSLT 変換処理するようにしたいなぁー。でも Xalan-Java じゃないと JavaScript 製のカスタム関数群が動かないのよね…。
ジャバスクのカスタム関数群は、文字列操作が死ぬほどウザイ XSLT/XPath 関数の替わりに用意してるのだけど、 AppleScript もやっぱり文字列操作がニガテな言語だったりしてて、うーん…。
要は、成績は中の中で良くも悪くもなくて、わりとまじめ君で、ぱっと見は優等生君で、クラスでは目立たない存在で、でもマジ根暗ってわけでもなくて、運動神経はニブそうで、自分で自分を誠実と思っていて、他人から見ても誠実なキャラで、それゆえ女子からイイヒトと思われやすいタイプで、よく「コード君」として利用されがちで、とはいえ女子関係はそれ止まりで、仲間内では自分と同じく最後まで売れ残る系で、まったくもって油断できるご同類だと思っていたのに、とつぜん女子扱いに手練ている様相を示し、同類一同が秘かに指をくわえて憧れていた、ウブでアカ抜けないながらちょっとカワイイ、ヲタ好みのあの娘に対して、ムード溢れる奇襲ちゅうをしくさるという出し抜きザマと、その予想外の手練と、女子に対する勇敢さをまざまざ見せつけられたもんだから、裏切られた気がするんでないかいな。
いやぼくもそのひとりですが。わら。
最近、いろんなアプリの aqua 風のスキンを見つけると片っ端から入れてるなぁ。
[ らぶらぶだいあり (2003/06/23) より ]
なんだかなぁ。あの OSX 10.0 リリース直前頃の、鬼のような Aqua フェイク狩りは何だったんだ…。
あの時（謎）のアポーの法務代理人の恫喝メールったらもう、すげぇこわかったさ（謎）。そんときの取り決めがあるから、このアマアマな状況下でもアレ（どれ）はもう公開できないのさ。なぜなら二度目の見逃しは無いという恫喝だったから。
ちうかデキの悪い Aqua フェイクはどんどん狩れよアポー。ぼくは Aqua が好きなのだ。こんなんが Aqua だと思われちゃタマラネー的なフェイクは数多いぞと。で関係ない話にどんどん繋がるわけだが、 OSX 10.3 では Finder までもメタル調になるのね…。多くのマカーたちは Aqua よりメタル調のほうが好きらしいんだけど、ぼかーキライ。メタル調な窓の上の方から Aqua の白シマシマのシートダイアログが出てくる様には鳥肌で悶えちゃう。違和感で。マカーたちは Aqua がそんなに好きじゃない。非マカーたちはなぜか Aqua が大好き。なんなんだ。寝るッ！
[ antipop (2003/06/23) 経由 ]
FOAF 本家の Weblog のある日の話題。日本における…というか、なぜかこの界隈（何処）の流行状況がネタになってて（笑）、「 foaf:weblog が使われてるヨ！（てことはつい最近考え出された要素なの？）」とか「日本語読めないヨーなんとか読みたいヨー」とか「この人らの foaf:name を自分の FOAF にコピペしたいんだけど文字化けしちゃって困ったなりーん」とか、そういう話。
ちるくるさんの例を出して、 RDF parser を通して得られた Unicode 文字参照値から XML の数値文字参照を導き出して、日本語文字「ちるくる」をどうにか表示するなどの、涙ぐましい努力をしていたり。
んで、今日ふたたび見に行ってみたら、われらの神・神崎氏が以下のコメントを付けていたのです。
A problem is the character encoding (or charset). Sometimes, they provide their FOAF as utf-8 while servers send iso-8859-1 charset param for .rdf or .xml files by default. And some people even use Shift_JIS (legacy, but most popular Japanese encoding) in their XSLT... In my environment, all browsers work fine with these tricky encodings, but might cause trouble for non-Japanese readeres.
（テキトー訳：問題は文字符号化方式（あるいは文字セット）。彼らは FOAF を UTF-8 で提供していながらも、サーバは .rdf や .xml に対するデフォルトの文字セット iso-8859-1 を送出してる時がある。そして、 XSLT （ XSL スタイルシート）に Shift_JIS （レガシーながら最も使われている日本語文字符号化方式）を使っている者もいる。ウチの全てのブラウザはこのトリッキーな符号化方式をうまく処理するけども、日本人以外（というか日本語非対応のアプリって事かな？）には問題を引き起こすかもしんない。）
むぅ。まずった。てことで、ウチの XSL スタイルシートは Shift_JIS だったのを全部 UTF-8 に変えて、拡張子 .rdf に対する HTTP 応答ヘッダの Content-Type フィールドも、単に application/xml とだけしていたのを application/xml; charset=UTF-8
となるようにしておいた。
でもどっちにしろ、アチラの使ってるブラウザ他のアプリケーションが UTF-8 に対応してて日本語フォントも揃ってなきゃ、日本語の扱いはどうにもならんモンなんスよねぇ…。ちうかイマドキは、 Windows のエイゴバンでも日本語フォントは用意されとるんですかいな？
ちうか、あちらさんは文字コードの事なんかいつも無頓着でいられるくせに、こちとら JIS/SJIS/EUC-JP/UTF-8 他モロモロの間でヒジョーに苦労しなきゃいかんっての、やっぱりどーにもくやしすぎ。もうメンドクサイから通常ページの HTML もその元になってる XML も 外部 JavaScript も外部 CSS も全部 UTF-8 にしようかな！ってその作業自体が強烈にメンドクサイや。あーあ。
「FOAF つくったですよ (2)」に関して。
他者が自分自身のことについて記している FOAF データを再利用ってのはまったくもって正しいとは思いますが、それをそのまま使うぐらいならば、むしろ rdfs:seeAlso の情報を使って FOAF データをそのまま参照してもらった方がよいとは考えます。だから、個人的には他者が自らのことを記したものを参考にしつつ、自分自身の主観で書いた方がよいのではないでしょうか。
[ FOAF データの再利用 - 行動記録 (2003/06/24) より ]
他人様の FOAF データ取り込みのメインの趣旨は、他人様本人申告の名前やニックネーム、メアド (foaf:mbox あるいは foaf:mbox_sha1sum) 、サイトや日記の URL 等の、その人に対するぼく自身の主観
もヘッタクレも無い、しかし正確なコピペが求められる項目を、いかにコピペ回数を減らして（つまるところ他人様の FOAF データ所在 URI のコピペ 1 回のみで）ラクして用意するか、なのでして。んでその勢いついでに foaf:interest とかも取り込んどけ、みたいな。
他人様についての、ぼくの主観でオーケーな項目を自前で用意しようと思えば、上記の主観介在無しの項目だけ選択してゲットし、あとはぼくの主観記述を反映するように XSL スタイルシートを変えるだけなのですが、他人に対する主観を述べるのは何か面倒を抱える気がするというかリスキーを感じる小心者なのでして（笑）
本当は foaf:knows/foaf:Person/dc:descrpition の内容も実はコワイ。パンピー個人サイトや同人サイトによくある（ウチにもある）馴れ合いリンクページと同じで、ありきたりな記述では意味も価値もないし、逆に的はずれな記述、あるいは当人にとって不当・不満な記述になってしまうとナニだし、コワイ。コワイコワイヒー。
そのわりには、いわいさんやにゃおりんのエントリあたり、冒険記述してるし（笑）
いよいよ正規版のリリース。ああ出ちまった…。ざっと使った感では、ぼくはまだ常用メインブラウザにはしないな。なぜかウチでは Camino のほうが速いし、やっぱり Gecko の標準実装度や表示に慣れちゃうとゼータクになってしまうので（笑）。ずっと MacIE5 だけ使ってきて、そこからの移行ならモロ手あげて移っただろけど。
んでまぁこのにっき的には、例によって自分のサイトをざっと観てみて気づいた標準仕様実装方面の、 beta2 (v73) からの変わったところ、変わってないトコロをうりゃうりゃとノベる次第なのです。
a 要素以外は title 属性値の内容を知る術が無い。xml-stylesheet 処理命令も理解するようなのだけど、 alternate="yes" が無視される。（→実例テスト）
クライアントサイドの XSLT は載ってない。まぁ Safari にこれが必要かって問われると、まだ必要な時勢ではないのかもしれない。
でも Safari の開発者 Dave Hyatt たんの Weblog Surfin' Safari の "Standards Support (2003/05/21) " で投げられた質問「 Safari でサポートしてほしい W3C 技術はどれ？」に対して、 XSLT を挙げるコメントは結構多い。
style 要素で HTML に直に CSS を埋め込んだ場合なら、 content プロパティ値に日本語文字を使っても文字化けしない …のは以前からそうだったけ？今となっては分かんないや。visible 以外の値が常に hidden 扱いになる件、直った。content プロパティの値に日本語文字使うと文字化ける。 @charset を明示してもダメ。ただしエスケープを使えば OK 。あるいは、外部 CSS の文字コードが UCS-2 であれば OK 。… UCS-2 って。（参考：UCS-2とUTF-8）
content: open-quote や close-quote を解釈できない。min-width, max-width, min-height, max-height を解釈できない。font-family は、どうやらフォント名に日本語の混じるモノは無視される。数値エスケープしてもダメ。clear に none 以外を指定すると、clear:none で値をカスケード上書きしても効かない。window.getSelection() が使えるようになった。んーでもこれを使ったスクリプトをボタンの onclick で発動するという良くあるやり方だと、そのボタンクリックの瞬間に選択範囲が解消されちゃうので、イマイチやりくりが難しいそう。ブックマークレットならいいけども。document.styleSheets[n].title はいつも null 。というよりは title プロパティを取り出そうとするだけでスクリプトエラーになるっぽい。てことで、スタイル切り替え JavaScript の類は相変わらず動作しません。もちろんこれは自分のサイトをちょっと見て回って気づいたトコに過ぎないので、改善点・現状維持なトコ、両方ともこれで全てじゃないです。それに、前提となってる標準仕様知識そのものが間違ってる可能性もあるわけで、そのへんは各自で仕様書とニラメッコして確認の事。
てなわけで、 beta2 (v73) での状況に合わせて施していた、ウチのサイトの Safari 対策の補正 CSS も、この 1.0 (v85) の状況に合わせて多少修正したですよ。サファラーな人はいちど Shift キーを押しながらリロードしてみてくださいな。以後当サイトでは beta 版 Safari の存在は考慮しませぬ。
というかこれ、 Safari 対策というよりは「 AppleWebKit 使用のブラウザ対策」であるので、 OmniWeb4.5 も対象になります。 OmniWeb4.5 も次のリリースで WebKit/v85 を使うようになるはず。
foaf:name は実名にすべきかどうか (2003/06/22 - 13:15)
The Web Kanzakiを読んでいて以下の記述に気付いた。
FOAFにおいてfoaf:nameは必須ではありませんので、本名を伏せたい時は、foaf:nickのみにしておく手もあります（foaf:nameの使い方に厳密な制約はありませんが、これをfoaf:nickと混用しない方がいいように思います）。なお、氏名の英文表記と漢字表記をどうやって両立させるかについては、議論中です。
あくまで神崎さんの解釈という注記はあるものの俺も迷っていた部分ではある。foaf:nameは制約がさほどなくても姓名のある実名を求められる気がする。少なくともfoaf:nameとfoaf:nickは同義ではないだろう。
そこまでは考えていたがWebリソースでは本名も匿名（固有ハンドル名）も同じように使われている。大体のところでIdentify出来る以上の厳密な個体識別を求められる場面は少ないし、実名を出すことのデメリットメリットを勘案して使い分けるという感じがする。だから、俺の周辺を見回た場合、foaf:nickがおおらかで実用的なIDなのだ。仮に実名を知っていたとしてfoafにして晒すのは余程仲がよくても断られるのではないだろうか?例えば、俺の実名を知っている人にfoaf:name****でfoaf:nickはdacで載せたいと言われたら十中八九断るだろう。
[ foaf:name - 適宜覚書_tDiaryVersion (2003/06/21) より ]
foaf:name はたぶん本名（実名）を記すものなんだろうなぁ、とは自分も考えていたのではあります。
このサイトは本来、同人サークル「娘娘飯店」のプロモーション（オオワラ）と、 Web 上での表現活動をその目的としているのです（でした？（笑））。それがどこでどう間違ったか、 Web 技術やマクネタに関して述べる比重のが圧倒的に高くなっている次第。いや、それはドウデモイイや。
現在ぼくが行っている表現活動はこれが全て。その全部、ずっと「ありみかさとみ」の名でヤってきた事。すでに 10 年間、この名前。今回用意した FOAF も、その表現活動を行ってきた「ありみかさとみ」というハンドル…ちうかペンネームの人についてと、その人が成した事を記述してるわけですやね。ほとんど大部分。 foaf:name に実名を書いたとしても、その実名の人はこの FOAF に記載されているその大部分に関わっていない。実名では ID として機能しない。…自分でさえそーゆー感覚がするのです。 10 年てのはそゆ感覚を醸成するのに十分な時間だ…。
ぼく（「ありみかさとみ」のぼく）を知っている人にとっても、それは同じだろなと。今さら実名を出すってのは、ペンネームの別名を作りましたのでみんな覚えてねー、とか周知活動しなきゃいかん気分さえする始末。
foaf:name は、 その FOAF が語る内容を成した人物の「最も通りの良い名称」、でいいのでわという考えです。んで foaf:nick は、その「名称」に対してエイリアスとして機能する別名あるいは愛称・蔑称 etc というあたり。「ありみかさとみ」の FOAF 的には、実名のほうが foaf:nick にあたるのかもしれない、とか言ってしまう勢い。おいおいおい。
「FOAF つくったですよ (1)」の続き
FOAF を作るにあたって、すでに公開してる人のモノをいろいろ見てみたのだけども、「こいつはめんどくさそーだー」と感じたのは、 foaf:knows のトコ。
自分についての foaf:Person はすらすらと書けるにしても、人様のは難しいのでありました。だいたい、その人のサイト URL や日記 URL やメールアドレスを調べるために、サイトを右往左往しなきゃならんくて、コピペ回数もハンパじゃなくって、一苦労じゃないかっ（笑）。
ましてや、人様が何に興味を抱いているかとか、そんなん勝手にリストアップして大丈夫かな、とか。あーいやいや、自他共に認めるホドそれが明白であったとしても、というかそれ以前に、人様の分の foaf:interest まで書く必要は特に無いのだけど。ともかく人様について、手動で確認を取りながらアレコレ記述 or コピペするのが、途方もなくメンドクサイそーに見えて、やってらんねーぞこれは、と。んでちょっと尻込みしていたのが真相。わらい。
しかしよく考えたら、本人自ら自分の事を明確に記した（ハズの） FOAF が、ネトワク的にすぐ手に届く場所に現にあるワケじゃないですか。それをこう、取ってきてですね、自分の FOAF の知人欄にそのままコピっちまえば、万事ラクチンに、内容も間違いのない、パーペキな foaf:konws セクションが出来るじゃん！と閃いた次第で。ちょっと出遅れたゆえの御利益ですなぁー。
とどのつまり、公開されてるお知り合いの FOAF ファイルの URL を羅列しておいて、それを引数に XSLT の document() 関数で引っ張っちゃえばいいんじゃんか！と。それならば、他人様について記すことは、 FOAF ファイルの URL と紹介文 (dc:description) だけで済むなぁと。手動のコピペが過ぎるんじゃ、なんのためのメタデータなのやら分かんなくなっちゃうし。
foaf_base.rdf は、ぼくの公開 FOAF ファイルを作成する前段階の RDF 。こういう記述が FOAF 的に、あるいは RDF 的に大丈夫なのかどうかは謎（RDF Validator は通るけど）。ともかくこれに foaf_predation.xsl を適用して、正規の foaf.rdf を生成してる次第ナノデス。
「FOAF つくったですよ (3)」に続く。
ちうことで最近ハヤリの FOAF をつくったですよ。あれやこれやの話はまたあとで。ハラヘッタ。ネムイ。
[ www.desktopper.net 経由 ]
WindowShadeX とか LabelsX とかでおなじみ Unsanity の Weblog 。なにやらちょっち金銭的に苦しい気がしてきたらしい。シェアウェアもみんなリーズナブルな小品ばかりだし、 WindowShadeX 3 でこれまでの「（レジストユーザは）生涯にわたって無料アップグレード」のポリシーを変えたいけど、どうよ？と問うてマス。
えげつないフィー取り立てなんかしないと、この Weblog でも蕩々とノベてるし、これまでの経緯からも信じられるし、好きなベンダだし、構わないんだけど。
あの苦しくキツかった OSX 黎明期に、旧 OS にあった機能を復活させるような小品をわりと迅速に用意してくれて、何とか OSX でもやっていけそうな気にさせてくれた恩はけっこうデカいな。 10.2 とか、 OSX が「人の住める土地」にまで開拓されてから移住してきた人には、あの時の光明感はピンとこないかもしんない。最近は Minimize In Place みたいな没ネタの復活とかでツボを付いてくるトコもホホエマシイな。
それは、裏を返せば、オリジナルのアイデアに乏しいという面は否めないわけだけど。無くなった機能や Apple 的にボツにしたネタも、何らかの理由があって実際の OSX には載らなかったわけで、正直、 OSX をメイン OS としてすでに久しく、違和感も何もなく環境に慣れまくりになった今ではもう、無くても困らない小品ばかりという面も。
WindowShadeX は、最初期バージョンの頃にレジスト以来ずっと使ってるのだけど、気づいた頃にはもっぱら OSX 標準の「 Dock へしまう」ばかりになってて、ちっともウインドウシェードをしなくなっていたという昨今。そろそろ外そうかなと思ったナイスタイミングで Minimize In Place 搭載な WSX3 が出て再びトキメキはしたのだけど（笑）、やっぱり外すかもしれない気分が漂ってたり、そういう感じ。
Mail to Alimika Satomi
Site search
About copyrights