履歴もしくは日誌

XHTML への移行と MIME タイプ

今まで，あまり考えてこなかったのですが，HTML 4.01 と XHTML 1.0，そして XHTML 1.1 なども使っています．HTML 4 と XHTML 1.0 は Web サーバが返すメディアタイプ属性が text/html で良い事になっていますが，XHTML 1.1 以降は text/html はだめよということになっていて，application/xhtml+xml 使いましょうということになっているようです．

• XHTML Media Types
  http://www.w3.org/TR/xhtml-media-types/#summary

HTML 4 から XHTML 1.0 への移行を検討したとき，そして実際に XHTML 1.0 を使い始めたときには，かなり注意深かったのです．でも XHTML 1.1 を使い始めたときは勢いでした．十分な検討をしませんでした．だから XHTML 1.1 でも実は text/html のままなのでした．これはやっぱり修正するべきですね．

問題は一つにディレクトリに，HTML 4 と XHTML 1.0 と XHTML 1.1 のファイルが混在していて，そのすべての拡張子が .html だってことなんです．

Web サーバでは，拡張子とディアタイプ属性を関連づけて，拡張子ことに，このフィイルのディアタイプ属性はあれこれですよっていう情報を HTTP ヘッダに付加しているんです．普段は Web ブラウザを使っていても見えないところですね．そう，XHTML 1.1 を使い始めるときに，異なる拡張子を使えば簡単だったのですが．

ざっと数えてみたら HTML 4 となっているファイルは約 200 ありました．これを XHTML に書き換えるのはできればやりたくありません．

HTML 4 以外が約 400 です．XHTML 1.1 を XHTML 1.0 に変換するのは比較的簡単そうですが，やはりあまりやりたくないですね．

なんとか HTML 4 の時には text/html で XHTML の時には application/xhtml+xml としたいところです．しかも，拡張子を単純に変更すると，リンクしなおさなくちゃならないですし，サイト内リンクは修正できますが，外部からのリンクにまで対応するのはちょっと無理です．

Cycling.jp の Web サーバは Apache を使っていますが，.htaccess という設定ファイルでこれを解決できないか考えてみました．

Options MultiViews
AddType "application/xhtml+xml; charset=iso-2022-jp" html
AddType "text/html; charset=iso-2022-jp" html4

Options MultiViews は，あるファイルが見つからなかった場合に，そのファイル名にさらに何らかの拡張子を付加したものがないか検索して，あればそれを返すっていうオプションです．これは拡張子が複数ある場合も機能します．

そして html という拡張子は application/xhtml+xml に，html4 という拡張子は text/html に割り付けます．

こうしておくと，newfile.html は application/xhtml+xml に oldfile.html.html4 はtext/html になります．拡張子は複数つけることが可能なのです．さらに http://onohiroki.cycling.jp/Bike.html にアクセスしたときに，Bike.html が存在しなくて Bike.html.html4 が存在する場合は，Bike.html.html4 が表示されます．

これなら HTML 文書間のリンクの関係も崩れないし，正しい MIME タイプが実現できるます．Web サイトへの訪問者は，おそらくファイル名の変更にも気がつきません．

SSI という機能を XBitHack という設定を使って実現している場合，AddType "application/xhtml+xml; charset=iso-2022-jp" html と設定すると，拡張し .html のファイルに対して SSI が効きません．

SSI の設定も書き加えると以下のようになります．

XBitHack full
Options MultiViews Includes
AddType "application/xhtml+xml; charset=iso-2022-jp" html
AddType "text/html; charset=iso-2022-jp" html4
AddHandler server-parsed html html4

XBitHack を使わなくても，AddHandler server-parsed を設定すれば，SSI は効くのですが，XBitHack も併用すれば，ファイルの更新情報が HTTP ヘッダに残ります．

この方法で，実際に問題になるのは XHTML ファイルが整形式 XML になっていないと，Web ブラウザで見た場合にも XML パーサエラーになることです．これまで HTML は，ちょっとくらい文法を無視していても，Web ブラウザが適当に表示してくれていたのですが，XHTML 1.1 移行はそうは行かなくなるぞって事ですね．

来月くらいから，この設定を行います．これで XHTML への移行が完了って感じですね．もちろん古いファイルは HTML 4 のままですけどね．ここでいう XHTML への移行は，HTML 4 の書き直しと言う意味ではないと言う事．

TrackBack

トラックバックとコメントの違い

ぼくのところには，トラックバックは用意したけど，コメントを書き加えることができるようにはしていません．

トラックバックは，ぼくが書いた記事に対して，誰かがなにかを書いたときに，ぼくに対して「あなたの記事に対して，この URL に何かを書きましたよ．」とお知らせする機能です．これは第 3 者にもわかる形で行われます．

コメントを書き加える機能がないから，トラックバックをコメントの代わりに使ったらどうでしょう．なるほど，見た目は同じと思えるかもしれないですが，意味が異なります．

トラックバックピン送信の画面には以下のような項目を用意されています．

• 記事のタイトル
• 記事の概略
• 記事の恒久的な URL

ある文章が Internet 上にあり，その文章を指し示す URL と，その文章のタイトルと，その文章の概要を記述するわけです．

だから，「URL で指している文章」と「概要」は関連があり，本文と概要という関係でなければなりません．

トラックバックは背後では XML によって，意味付けされたデータとして扱われていて，トラックバックを表示する画面ではコメントの様に見えていても，XML で記述したものは意味をなさないものになってしまいます．

目で見えるものだけしか気にしないか，
どういう規格/ルール/意味かも気にするかという事の違いです．目で見えるところだけしか気にしなければ，その人が見ていない部分で破綻を来すわけです．

TrackBack

文字実体参照と Exposé

• 文字実体参照の定義 (英文)
  • Character entity references in HTML 4
    http://www.w3.org/TR/html401/sgml/entities.html
  • XHTML Latin 1 Character Entities
    http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_XHTML_Latin_1_Character_Entities

HTML や XHTML での文字実体参照の定義によると e の上に「’」みたいなのがついた文字「é」は，é と書くか é と書けば，表示されるってことになっています．これは表示する環境が対応していないとだめなんですけどね．最近の Web ブラウザならほぼ大丈夫でしょう．

• アップル - Mac OS X - Panther - Exposé
  http://www.apple.co.jp/macosx/panther/expose.htm

アップルでも Mac OS X 10.3 の新機能 Exposé の表記に使ってますね．この Exposé というのは，沢山のウィンドウを開いているときに，どうやって整理するか，どうやって他のウィンドウを参照したり，他のウィンドウに移動するかという問題に対して，ユニークな解決方法を提案する新機能です．とても評判が良いのであちこちで話題になっているんですが，この Exposé の書き方が皆，適当なので．まぁちゃんと表示できない環境があるのは本当ですが...

そうそう，HTML/XHTML では，é と書いてよいけど，RSS とかの XML では一般的にだめなのです．どこかで定義しないといけません．簡単には é と書けばよいのでしょう．

TrackBack

「RSS拡張の試み」についての続き

「RSS 拡張の試み」について masano さんの案の例について：

ご指摘の意味がよくわかっていないのですが、もしかして、サンプルにおいてrdf:about="***.rdf" となっていたのがいけなかったのでしょうか。

と，いう反応がありました．

• 「RSS拡張の試み」についての続き / msano@semblog.org
  http://www.semblog.org/msano/archives/000220.html

まず，ぼくが書いたところで，書き間違いがありました．

で，ぼくにはよくわからなかったのは，channel 要素で示しているものと，item 要素の関係がよくわからなかったんです．RDF ファイルを指しているからというよりは，ファイルが実在しているものだったから，実際のそれらのファイルの関係と，例で記述されている関係とがなんか違うような気がして混乱しました．

新しいサンプルを見て，その点はよくわかりました．すっきり．

補足説明ありがとうございました．

TrackBack

平野さん運営のアンテナ

自分の運営している「おのひろきあんてな」という更新時刻情報付きリンク集であるいわゆるアンテナよりも，平野さんが運営しているアンテナのほうが良いとおもっています．

平野さんのは各 Web サイトの更新部分の要約がでるんです．

でも RSS は提供されていません．あれが RSS になったらすばらしいのですが．

それで平野さんに RSS の提供もして下さいとお願いしておきました．

• HRK's Ad-hoc Antenna
  http://www.ne.jp/asahi/diver/hrk/antenna/

TrackBack

文書間関係と RSS について

「RSS拡張のこころみ（その2）について」ですが，TrackBack のことはすっぱり忘れて，ある記事がどこにリンクしているか，どこからリンクされているかを表現するということで良いのではないでしょうか．

• RSS拡張のこころみ
  http://www.semblog.org/i2k/archives/000210.html
• RSS拡張のこころみ（2）
  http://www.semblog.org/i2k/archives/000216.html

ここでは out と in という語彙を定義する事を提案しています．

http://www.semblog.org/ns/semblog/0.1/out

あるエントリ(記事)に含まれるリンクのURI

http://www.semblog.org/ns/semblog/0.1/in

あるエントリ(記事)が受けたTrackBack Ping元のURI

out と in ではなく linkto と linkfrom として，linkto は，RDF の主語になる記事がリンクしている先を示し，linkfrom は，RDF の主語になる記事にリンクしてきている URI を示すということにしてはどうでしょう．

linkfrom は TrackBack Ping の受信から生成しても，アクセスログから生成してもいいし．linkfrom を別ファイルで示す場合は，rdfs:seeAlso を使うとか．

そうなっていればぼくも実装できそうです．

なんてことを書いていたら，神崎さんのページが更新されて，このような事を Dublin Core の精密化要素 （拡張語彙）で定義されている references と isReferencedBy を使って表現する方法の紹介が書き加えられました．

• RSSとトラックバック
  http://www.kanzaki.com/docs/sw/rss-trackback.html

references が，こっちからリンクしている先の URI で，isReferencedBy が，こっちにリンクしている記事の URI です．なるほど，新たな語彙を提案しなくても，すでにある語彙で表現できたのですね．

references のほうならすぐにぼくも試すことができそうです．isReferencedBy は，RSS に直接入れるのは，ぼくの環境では面倒かな．別ファイルのほうが面倒少ないと思いました．

msano さんが，提案している１つのコンテンツ（つまり、item）を示すRSS風メタデータは，おもしろいと思ったけど，よくよく見てみると，ぼくにはよく分かりませんでした．

• msano@semblog.org: 「RSS拡張の試み」について
  http://www.semblog.org/msano/archives/000213.html

もし <channel rdf:about="ある記事のURI"><items/><semblog:ins/><semblog:outs/></cahnnel> となっていれば，ins や outs で記述されているのが，channel rdf:about で示される記事についてって事になると思いますが，例でしめしてあるような RDF の場合は，ins や outs はそれぞれ何を示しているのでしょうか?

TrackBack

はてなアンテナとファイルが見つかりませんエラー(404)と正体不明のロボット

自分の Web サイトのエラーログを見ていると，ときどき
http://onohiroki.cycling.jp/20031022091733
とか
http://onohiroki.cycling.jp/index.html20030922190630
という，存在しないファイルへのアクセスがエラーとして，残ります．これはいったいなんなのかと．うざったいなって思っていました．

数字が余分なんですよね．数字をよく見ると西暦，月，ひ時間，分，秒となっているような気がします．

なんかのアンテナから飛んでくるとは思ったんです．

ぼくが用意したプログラムに残ったエラーの記録で，最近のものはこんな感じ：

• HTTP_REFERER: http://onohiroki.cycling.jp/20031022091733
• REQUEST_URI:/20031022091733
• HTTP_USER_AGENT:Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
• localtime:2003-10-23T14:59:31

これは，REQUEST_URI はアクセスしようとした URL なのですが，この数字の列が日付けと時刻を表しているとしたら，実際にアクセスした時間(localtime) と 1 日くらいずれています．
それにリンク元を示す HTTP_REFERER は，リクエストしている URL になっています．

このことから，MSIE 5.01 によるアクセスではなくて，どこかの情報収集プログラム (ロボット) によるものではないかと思うのです．そのロボットははてなアンテナの HTML を解析したときに，URL の認識を間違えるのです．

はてなアンテナは http://a.hatena.ne.jp/go?http://onohiroki.cycling.jp/20031022091733 っていうようにリンクを作って，そこから転送する仕組みになっているようなのですが，そのロボットは，go? のところで区切って 2 つの URL と認識しているんでしょうな．

その正体未確認のロボットは，HTML ファイルを取得して保存して，そのなかから http:// で始まる文字列を探してきて，その URL でアクセスして HTML 文書をまた取得する．それを繰り返す仕組みなんでしょう．そうして集めた情報で検索エンジンサービスみたいなことでもやるつもりなのでしょうか．それが，はてなアンテナのページを解析する時に間違った URL を抽出して，抽出した URL にアクセスするまでに 1 日くらいあったんでしょう．そしてあちこちで不正な URL でアクセスを試みてエラーを発生させていると．

はてなへの要望として http://a.hatena.ne.jp/go?http://onohiroki.cycling.jp/20031022091733 ぢゃなくて，http://a.hatena.ne.jp/go?onohiroki.cycling.jp/20031022091733 というような途中の http:// を省いた形式にして欲しいです．そうすれば，変なプログラムが間違った URL でリクエストしてくることはなくなるでしょう．

そうでなかったら，そのロボットのアクセスを禁止するのかな．どこの IP アドレスからのアクセスかを確認して，その IP アドレスからのアクセスを禁止すればいいのかな．

TrackBack

メタデータを記述する手段としての RSS

RSS 1.0 をどう利用するかですが，Site Summary (サイトの要約)であるとか，syndication (記事の配給) という事にこだわらずに，インターネットで公開する文書のメタデータを記述する手段としてとらえたほうが面白いかも．

Web ページ用に HTML 文書を作った時に，HTML 文書の部分ごと，パートごと，構成要素ごとに id を属性として与えるなどして，それら個々について RDF としてメタデータを記述して行くんです．

すると，ここの部分は誰それが何について書いて，あっちの部分はあっちのサイトが配布しているものを差し込んでいて，ここの部分はあそこからの引用で，ここで言及しているのはどこについてのコメントで，ここの画像は誰それがどこで何を撮影した画像で....という具合に RSS の方が HTML 文書よりも，より多くの情報を明確に記述できそうですね．

すると RDF でコンテンツを書いて公開するのが前提で，古いソフトウェアを使っている人のために HTML に変換したものも公開しておくかって感じになったりして．

TrackBack

Web ページと RSS の関係(2)

自分で読み返してみても前回の文章は分かりにくいものでした．Web ページと RSS の関係について考えてみたことをもう一度まとめてみます．

ある Web ページがあって，そのページと同じ機能/目的を異なる方法で用意したものは，代替として link 要素で rel="alternate" として示しても良いと思います．たとえ代替がすべての内容を含んでいなくてもです．

• もとのページが日本語で，英語のページを用意した
• もとのページはパーソナルコンピュータ向けで，小型携帯端末用に異なるページを用意した

これらが，代替であるなら，つぎの場合も代替ではないのでしょうか．

• メディアタイプが text/html を解釈するユーザエージェント向けの HTML 文書のかわりに，application/rss +xml を解釈するユーザエージェント向けに XML ファイルを用意した

では，もとの HTML 文書とそのメタデータである XML ファイルの関係はどうなっているのか．メタデータを記述した XML ファイルである RSS が HTML 文書の代替となり得るのか．

ぼくはなり得ると思います．

weblog もしくは blog の Web サイトのトップのページは，最新の記事のいくつかを表示するもので，RSS では最新の記事のタイトル一覧だけかもしれませんが，機能的にはそれで代替としてなりたっていると思うのです．トップページの内容すべてをカバーしていなければ代替とは言えないとは思わないのです．

weblog のサイトなら，個々のエントリー(記事)の独立したページがあり，それが主なコンテンツで，サイトのトップのページはそれらの最新のいくつかを紹介するのが主な目的でしょう．その時に，個々のエントリーの全文が読めるかどうかは，あまり問題ではないと思うのです．だから RSS に，エントリーの全文が含まれていなくても，「最新のいくつかを紹介する」という主な目的は果たすのかなと．

TrackBack

Web ページと RSS の関係

Web サイトの最初のページ/トップのページ (用語では Welcome ページ) の機能を考えると，たいていはその Web サイトの内容の見出し一覧になっているのではないでしょうか．その Web サイトの各ページへのリンクとか，最近更新があったページの一覧とか．そして日記/日誌を公開していれば，それらの最新のいくつかのトピックスが Welcome ページにあったりします．いわゆる Weblog もしくは blog という形態の Web サイトなら，Welcome ページは最新のいくつかの記事 (用語ではエントリー) が表示されているでしょう．

Welcome ページの中では，頻繁に更新される動的なものと，あまり行進されない静的なものとの両方があるでしょう．

RSS が，Welcome ページからリンクされるなら，Welcome ページの中の頻繁に更新される動的なものの要約を表現した RSS にリンクされるでしょう．
Web ページを閲覧する Web ブラウザのための Welcome ページに対して，Web サイトの要約一覧である RSS を扱う RSS ビューア (用語では，RSS Aggregator) 用に提供する RSS．この 2 つの関係はどういう関係でしょう．

RSS をコンピュータが発見できるように HTML の中に情報を記述する方法として，以下のような書き方があります：

<link rel="alternate" type="application/rss+xml" title="RSS" href="http://onohiroki.cycling.jp/info/weblog.rdf" />

これの alternate というのは代替という意味なのですが，RSS が Web ページの代替なのかという話が「はてなダイアリー - in the vanguard」にありました．

• Suggestion for RSS -linking in HTML (Draft 2) / はてなダイアリー - in the vanguard
  http://d.hatena.ne.jp/kotastyle/20031020#p1

例えば iモード用に Welcome ページの代替を用意する時にはまったく同じ内容なのではなくて，iモードで閲覧できるような内容に制限もするし，iモード専用のコンテンツへのリンクを追加したりするでしょう．

Web のコンテンツにアクセスするソフトウェア/ User Agent はいろいろあって，User Agent にあわせたコンテンツを代替として用意するってことです．

Web サイトの要約一覧を扱う User Agent の為に Welcome ページの機能の一部である，「頻繁に更新される動的なコンテンツへのリンク」だけを抽出して，それを Welcome ページの代替として提供するという考えではおかしいでしょうか．

RSS を Welcome ページの代替として考えたら，頻繁に更新される内容を RSS で提供し，あまり更新が無い部分は RSS に適用される XSLT で提供するとか．そうしたら RSS を Internet Explorer で表示した時に XSLT を使えば，Welcome ページとほぼ同じものが再現できるでしょう．そのときに Welcome ページでは，日誌の記事の全文が読めるけど，RSS だと日誌の記事の要約だったとしても，どちらもその記事全文へのリンクを持っているなら，頻繁に更新される日誌の記事の最新のいくつかの一覧と言う意味ではあまり変わらない機能を提供していて，むしろ RSS を扱う User Agent 向けとしては適切な代替かなと．

「はてなダイアリー - in the vanguard」の記事を見るまでは，そんな事は考えもしませんでした．

TrackBack

Google 検索の言葉の定義とセマンティック・ウェブ

SEO / SEM Research によると Google 検索に言葉の定義を求める新機能が追加されているそうです．どう検索されるかの例はありましたが，これがなんの役に立つのかの例はありませんでした．これは RDF で，メタデータを記述する時に，とっても便利なのではないでしょうか．

• Google で言葉の定義を探す "define:" - SEO / SEM Research
  http://www.sem-research.jp/sem/google/20031021073120.html

RDF と言ったら RSS 1.0 とか FOAF ですね．
例えば FOAF である人が人が関心を持っていることに関するページを示す foaf:interest では URI を rdf:resource 属性値として書かなければならないのですが，サイクリングに興味があると記述するには，サイクリングを説明したページがなくちゃならないわけです．

例えば，トライアスロンに興味があれば，それの公式なページってあると思うんです．それがサイクリングなんてより一般的になると，どれが適切か悩むことになるし，サイクリングというより自転車そのものが好きなのだって話になると「自転車に興味がある」ということを適切に示す URI って何になるのかなと．

その時に，Google 検索の言葉の定義を求める機能って使ってみたらどうでしょう．bicycle ならこうなりますね：

• http://www.google.com/search?q=define:+bicycle

まぁ，RDF では，これよりも WorldNet のほうが適切かもしれません．WorldNet については，神崎さんの「日本語ウェブ・オントロジーの試み」に説明があります．

• 日本語ウェブ・オントロジーの試み
  http://www.kanzaki.com/docs/sw/jwebont.html

あと，RDF でメタデータを記述しておいて，それを Web ページに変換する時に，RDF では WorldNet を使っておいて，RDF を Web ページに変換する時に，WorldNet は Google 検索へのリンクに変換するのは良い方法かも．

画像のメタデータを記述する実験である「SwPhotoAlbum / 画像アルバム」では WorldNet を使って画像の被写体が何であるかを表現することを試しています．メタデータから Web ページを生成する時に WorldNet へのリンクを生成しても意味ないなって思っていたのですが，Google 検索へのリンクを生成するのは良さそうだと思いました．

まぁでも Google 検索で言葉の定義を求めるのを試してみると，実は WorldNet へのリンクがやっぱり出てくるわけです．むしろそういう辞書のような Web サービスだけではなくて，個人が書いた用語集のページの定義が検索で拾われるのがすごいなって思いました．Google は HTML の meta 要素から用語集のページだと認識できるのでしょうか?

TrackBack

Trackback と RSS について(2)

昨日話題にした，Trackback モジュールについての記述が神崎さんの「RSS(RDF Site Summary)によるサイト情報の要約と公開」に追加になっていました．

• Trackbackモジュール / RSS(RDF Site Summary)によるサイト情報の要約と公開
  http://www.kanzaki.com/docs/sw/rss.html#mod-tb

trackback:ping と trackback:about についても分かりやすく説明されています．この説明の中に以下のような記述を見つけました：

いずれも プロパティ要素として目的語URIを記述するので、 rdf:resource 属性を使います（ rdf:about ではない！）

引用終わり

これを読んではっとしました．rdf:about ではない! と感嘆符付きです．昨日自分が書いたのを見たら，間違いがあったので，こっそり修正しました．

ここで，Trackback を送ってくれた相手の URI を記述するプロパティが Trackback モジュールにない理由も説明がありました．これは「semblog-dev: RSS拡張の試み」での話題に関連している話ですね．

TrackBack

TrackBack と RSS について

TrackBack Ping の送信先の情報などを RDF として HTML/XHTML の中に埋込むということが TrackBack の仕様にあるわけです．

が，しかし，Movable Type という Weblog ツールでは， RDF を XHTML の中にコメントとして埋込んでいます．これはあまりかっこいいやり方ではないなって思うのです．
ではどうすればいいかと言われても，ぼくが技術的に解決できるようなアイディアを持っているわけではありません．
とりあえず，自分のところでは TrackBack の情報を RDF として記述して XHTML の中に埋込むことは見合わせています．

RDF なら RSS 1.0 の中に埋込めば自然だろうとぼくは思ったのですが，すでに RSS の拡張モジュールとして trackback モジュールがあったわけです．
さっそく自分でも試してみたわけです．それはいつからだったか．

それからそれから．

• semblog-dev: RSS拡張の試み
  http://www.semblog.org/i2k/archives/000210.html

ここでは各記事について TrackBack の関係を RSS 1.0 の形式で記述する方法が検討されています．ぼくは trackback モジュールとの関係なんかを考えながら記事を読み進めて行ったのですが，ページの最後のコメントのところに，いしだなおとさんのコメントがあり：

【受信したTrackBack PingをあらわすRSS要素】 同じくtrackbackモジュールで、「trackback:about」という要素が定義されていて、それが相当するもののようです。 まるで普及していませんが、おのひろきさんのところのRSS では採用されていらっしゃるようです。

なんて書いてあってびっくりしました．自分の名前が出てくるとは思わなかったんで．

で，びっくりしたついでに，良く読み返してみると受信したTrackBack PingをあらわすRSS要素とありました．それの必要性はよく分かります．よく分かりますが，それを実装するのは，ぼくのところでは難しそうだなって思いました．さて? ぼくのところではどうなっていただろうとふと思ったのです．

以下，接頭辞 trackback は http://madskills.com/public/xml/rss/module/trackback/ という名前空間に関連付けられているとします．接頭辞 semblog は http://www.semblog.org/ns/semblog/0.1/ という名前空間に関連付けられているとします．

trackback:about 要素は，受信したTrackBack PingをあらわすRSS要素なのですが，ぼくは勘違いして，TrackBack Ping の送信先を trackback:about 要素として記述してた?

いや，仕様をよく読むと，やっぱりその記事で言及して TrackBack Ping を送信した先を trackback:about に書くのではないでしょうか?

semblog:in の例を見てみましたが，item 要素の rdf:about 属性と RSS の link の内容と semblog:in の内容が同じになるようですが，冗長な感じがします．

提案されている仕様と違うけど RSS 1.0 の中で item 要素の中に以下のように書けると良いのではないでしょうか：

<item rdf:about="http://www.semblog.org/i2k/archives/000210.html">
	<link>http://www.semblog.org/i2k/archives/000210.html</link>
	<title>semblog-dev: RSS拡張の試み</title>
	<semblog:in>
		<item rdf:resource="http://onohiroki.cycling.jp/index-log200310.html#d20031020n2">
			<title>TrackBack と RSS について</title>
		</item>
	</semblog:in>
</item>

もしくは

<item rdf:about="http://www.semblog.org/i2k/archives/000210.html">
	<link>http://www.semblog.org/i2k/archives/000210.html</link>
	<title>semblog-dev: RSS拡張の試み</title>
	<semblog:in rdf:resource="http://onohiroki.cycling.jp/index-log200310.html#d20031020n2"/>
</item>

どうでしょう?

あと，ある記事が受け取った TrackBack を RSS にするというのは trackback スタンドアロン実装の CGI に RSS 0.91 形式のファイルを生成する機能があります．それが「semblog-dev: RSS 拡張の試み」での例と同じことをしていると思うのですが，trackback スタンドアロン実装の CGI のは RSS 0.91 ですから特に新しい語彙を定義しているわけではないです．

Web サイトの RSS 1.0 の中である記事を記述する時に，その記事について受け取った TrackBack を記述した別ファイルの RSS を指し示す方法があると便利かも．

<item rdf:about="http://onohiroki.cycling.jp/index-log200310.html#d20031020n2">
	<link>http://onohiroki.cycling.jp/index-log200310.html#d20031020n2</link>
	<title>semblog-dev: RSS拡張の試み</title>
	<rdfs:seeAlso rdf:resource="http://onohiroki.cycling.jp/tb/tb_rss/weblog_d20031020n2.xml"/>
</item>

あと RDF として考えたら，
<semblog:in>http://onohiroki.cycling.jp/index-log200310.html#d20031020n2</semblog:in>
という書き方よりも
<semblog:in rdf:resource="http://onohiroki.cycling.jp/index-log200310.html#d20031020n2" />
のほうが良いのだろうと思います．

後になってから，一部で rdf:about を rdf:resource に書き換えました．

TrackBack

再起動

昨日 15 日の 16 時ごろから本日 18:30 ごろまで，おのひろきおんらいんを含む Cycling.jp の全サービスが停止していました．

本日 18:30 ごろから Cycling.jp のサービスが再開されました．

再起動ぢゃなくて，サービス再開．どうもサービス停止中もサーバは動いていたようで，別に再起動しているわけぢゃないみたい．アクセスログがきちんと動いていたから．サービス停止中のログには Cycling.jp で運用しているアンテナが Cycling.jp 内のコンテンツのチェックをしているのだけが記録されていました...

TrackBack

TinyURL

Yak というメーリングリストで，TinyURL.com というのが話題になっていました．まきさんがその話題について投稿していたので気が付いたのです．

• TinyURL.com
  http://tinyurl.com/

なんせ英語のメーリングリストなんて通して読む元気がないので，Japan っていうキーワードがメールに含まれていたら，色を変えて表示するようにメールソフトを設定しているのです．だからまきさんの投稿でどれどれって読んでみて，その話題に気が付いたという次第．

さて話題になっていた TinyURL.com ですが，どんなことをしているかというと，長い URL を登録すると，それの代替になる短い URL を提供して，その短い URL にアクセスがあったら，登録されているもともとの長い URL に転送するっていうサービスを提供しています．

例えば，「おのひろき」を Google で検索した結果の URL は，こんなになります．

• http://www.google.com/search?q=%E3%81%8A%E3%81%AE%E3%81%B2%E3%82%8D%E3%81%8D

長いですね．これを TinyURL.com のサービスを使うと：

• http://tinyurl.com/r3yc

このように非常に短い URL に変換してくれます．

URL が短いと友達にメールで URL を知らせる時とか便利ですよね．やたらに長いと，変なところで改行されちゃったりするぢゃないですか．

利用する上で不安なのは，TinyURL.com のサービスの永続性です．TinyURL.com が存続する限り，一度発行した URL が有効なのかと，TinyURL.com 自体がいつまでサービスを続けられるか．

そこまで考えると，友達とメールでやりとりするときなどの利用にとどめておくのがいいのかなと思いますが，いろいろ工夫した面白い使い方がありそうですね．

TrackBack

アナウンス

まきさんから，BD サイクリングクラブメーリングリストと，リカンベントサイクリングクラブメーリングリストに，アナウンスがでました．

BD サイクリングクラブメーリングリスト の [BD cycling:13678] から引用すると：

人為的なミスにより現在Cycling.JPの各サービスが停止中です。（atnak.com含む）
復旧は明日10/16 18:00頃の予定です。

とのことです．

現在はメーリングリストは cycling.jp とは別のシステムで運営してるのですが，やっぱりそれが正解かなって思います．Web サイトとメーリングリストが同時に落ちる確率が小さくできるから．

TrackBack

Cycling.jp 復旧は明日 16 日の 18:00

まきさんから連絡があって，Cycling.jp 復旧は明日 16 日の 18:00 と言うことでした．

いやー，まいった．

TrackBack

Cycling.jp サーバダウン

2003 年 10 月 15 日 16 時現在サーバがダウンしています．

今日の午後になってから cycling.jp のサーバと接続できなくなりました．吉田さんとまきさんも事態に気がついえいるようです．サーバ管理は，吉田さんとまきさんが分担して行っているので，ぼくは二人の活躍に期待して，ただ待つだけです．

TrackBack

おとなりのページは?

はてなで，新しいことを試しているようです．「おとなりページ」というものなのですが，なかなか面白そうです．

• はてなダイアリー - はてなダイアリー日記 おとなりページ開始について
  http://d.hatena.ne.jp/hatenadiary/20031013

はてなでは，以前からおとなりなんとかという機能で，関連のあるなにかを表示するという機能をあれこれ実現していましたが，今回のおとなりページが一番面白いのでは．

はてなアンテナで補足されているページに対して，他にどんなページが同じアンテナから補足されているかというのを解析して，おとなりページとして表示しているようです．

ぼくの場合は，自力で運営してるアンテナがあるので，おとなりページで表示されるものは，自力で運営しているアンテナのカテゴリのものが少なめになっている気がします．おもにすーさんのまわりのコミュニティの人のアンテナの影響が強いように感じますな．っていうか，あまりはてなアンテナには登録されていないってことですね，ぼくの Web サイトが...

• "おのひろきおんらいん"の おとなりページ
  http://a.hatena.ne.jp/map?http://onohiroki.cycling.jp/

TrackBack

FOAF と RSS の記述方法で気付いたこと

それで，神崎さんの「FOAFとRSSを用いた画像メタデータ」というページを読んでみて，いくつか発見がありましたし，ぼくが書いた RSS や FOAF にはいつくか問題がある事がわかりました．

RDF の事がよく分かっていないために，怪しいと思っていたところが正しかったり，大丈夫だと思っていたとこが間違いだったりしました．気が付いた事を列挙します．以下の接頭辞 foaf は FOAF の名前空間に関連しているものとします：

• foaf:page の使い方を知りませんでした
• foaf:topic の使い方を知りませんでした
• RSS の item 要素が画像ファイルを指している場合：
  • item 要素の子要素として，foaf:thumbnail を持って良い
  • item 要素の子要素として，foaf:Person は置けない
  • item 要素の子要素として，foaf:depicts を置き，その depicts の子要素として，foaf:Person を置けば良い
  • item 要素の子要素として，foaf:page が置ける
• RSS の item 要素が画像についての Web ページを指している場合：
  • item 要素の子要素として，foaf:topic という要素を置ける
  • foaf:topic の子要素として，foaf:Image が置ける
  • foaf:Image の子要素として，foaf:thumnail や foaf:depicts が置ける

てな訳で，また時間を見つけて "SwPhotoAlbum / 画像アルバム" の RSS や FOAF を生成する XSLT の部分を書き換えです．

TrackBack

FOAFとRSSを用いた画像メタデータ

神崎さんの Web サイトで画像のメタデータを RSS や FOAF を利用して表現する方法を解説した「FOAFとRSSを用いた画像メタデータ」というページが公開になりました．

• FOAFとRSSを用いた画像メタデータ
  http://www.kanzaki.com/docs/sw/image-rdf.html

ここしばらく画像のメタデータをどうやって記述したものかという事に関していろいろ試してきたのですが，やっとお手本にできるものができてとてもうれしいです．

FOAF で画像を説明する方法とかRSSを使った画像メタデータの公開方法などは，まさにぼくがどうしたものかって悩んでいた事です．

RSS では画像自身をアイテムとするチャンネルとするか，画像を表示している Web ページをアイテムとするチャンネルとするかの両方が検討されていました．

あと先日ちょっと触れた pheed の事についても神崎さんも触れています．そこで指摘されていますが，画像を表現するために pheed 等のように独自の語彙を使うよりは，FOAF とか RSS のように，すでにあるものを利用したほうが良さそうですね．

画像自身の検索やデータベース管理を効果的にする為に画像のメタデータを用意しようということなのですが，まだすぐに何かが便利になるわけでもないでしょう．将来，Internet での画像の検索が自在にできるようになったり，自分のコンピュータで画像を整理する時のデータの扱いが統一された方法になったりした時には，一般の人の気が付かないうちに，背後でこういう技術がベースになっているのでしょうね．

まずはデジタルカメラで撮影した画像ファイルから半自動的に Web ページを生成するようなツールで，こういう技術を実装するべきですね．

RSS の形でデータを公開するなら，RSS を利用するソフトウェアでもサムネイル画像などを表示する機能が期待されるのですが，神崎さんの Web サイトの RSS を Web ページとして表示するプログラムでは，サムネイル画像を表示する機能がすでにあるそうです．

• ぼくの "SwPhotoAlbum / 画像アルバム" の RSS を神崎さんの Web サイトの RSS を表示するプログラムで表示した例
  http://kanzaki.com/test/rssfr?u=http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/rss.rdf

その他の，このトピックスに関連するページ：

• SwPhotoAlbum / 画像アルバム
• 履歴もしくは日記から RSS について
• 履歴もしくは日記から FOAF について

TrackBack

HTML2MOBILE Lite うまく動かず

i モードなど携帯電話でもここのページを閲覧できるように HTML2MOBILE Lite という CGI を使って，携帯電話向けに変換するサービスを運用しています．

昨夜それの CGI を書き換えて，いくつか機能を追加したんです．

• 文字コードが UTF-8 のページへの対応
• TrackBack の画面に移動しても，正常に表示できなかったので，TrackBack 関係のリンクを表示しないように
• "SwPhotoAlbum / 画像アルバム" のページで，iモードでアクセスした時に，サムネイル画像へのリンクを生成

昨夜はうまくできたと思ったのに，今朝試したら一部でおかしなことに....

簡単には修正できないことが分かったので，しばらくはこのままです．ちょっとおかしいところもあるのですが，携帯電話で "SwPhotoAlbum / 画像アルバム" のページを見なければ問題はないようなので．

TrackBack

はてなダイアリの RSS

はてなダイアリの RSS が公式に配信開始されました．いままでは，けんたろさんが提供してた Hatena RSS Machine とうのを利用させてもらってきたのですが，今回公式に配信が始まることになったってことで．

• はてなダイアリの RSS が公式に配信開始 / antipop
  http://antipop.zapto.org/?id=914

これで RSS もより普通に使えるようになったということでうれしいです．

国内の Web 日記サービスってものがある程度できてきて，海外からの Weblog 文化の RSS とか TrackBack とかが取り込まれて行くっていうのは面白いなぁと．

TrackBack

画像のメタデータと pheed と RSS

myblog.jp 最新記事一覧で，「C O U L D：　写真家用のRSS」という記事を発見し，pheed の事を知りました．

• C O U L D：　写真家用のRSS
  http://www.yasuhisa.com/could/entries/000298.php
• pheed / Syndicated Photography Feed
  http://www.pheed.com/

C O U L D：　写真家用のRSS から引用します：

確かにこれがデータベースとして蓄積されたら、Googleのイメージ検索より正確に見たい写真にたどり着くかもしれませんね。

RSSといえば、ニュースのような常にフレッシュな情報を提供しているサイトに有効なフォーマットというイメージがありますが、いろいろな使い方があるのだなと感じました。

引用終わり．

現在は，Internet で適当に画像を公開しても，画像を検索エンジンでうまく検索するのは難しいですよね．それは画像ファイルに対して、メタデータを用意することで解決できると思うのです．メタデータを用意する方法はいろいろ提案されているみたいですが，pheed も良さそうですね．

RSS のいろいろな応用っていうことでは，神崎さんも言及されていました．

• 写真/画像とメタデータ -- EXIF/TIFFを利用したJPEGとRDFの連動
  http://www.kanzaki.com/docs/sw/photo-rdf.html

この中の RSSを使った、さまざまなメタデータの連動から引用します：

RSS はサイトの更新情報の配信だけでなく、さまざまなメタデータを組み合わせて提供するコンテナとしての可能性を秘めています。日付データと地理データを媒介に、いろいろなメタデータを連動させると面白いと考えています。

引用終わり．

神崎さんはデジタルカメラで撮影した画像ファイルの EXIF データを RDF として記述する方法を提案されていて，それが RDFの応用などを協議する RDF-IG で標準スキーマの候補となっているそうです．ぼくは，これがまとまるのがとても楽しみです．

それで，pheed ですが，RSS 2.0 の拡張となっています．RSS には RDF の応用の RSS 1.0 と，RDF の応用ではない，RSS 0.9x と 2.0 があります．pheed は RSS 2.0 の拡張なので RDF の応用ではありません．
pheed では，Dublin Core の使い方の提案が面白いなって思ったのですが，Dublin Core は pheed 独自のものではありません．Dublin Core の部分は一部を省略して pheed の item 要素の例を下に示します．接頭辞 photo は http://www.pheed.com/pheed/ に関連付けられています．

<item>
    <title>出発の朝</title>
    <link>
    http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/?DSCN2800.JPG
    </link>
    <description>駅から出発です．</description>
    <dc:creator>ONO Hiroki</dc:creator>
    <dc:rights>Copyright 2003 ONO Hiroki</dc:rights>
    <photo:imgsrc>
    http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/DSCN2800.JPG
    </photo:imgsrc>
    <photo:thumbnail>
    http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/thumbnail/DSCN2800.JPG
    </photo:thumbnail>
</item>

分かりづらいですが，http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/?DSCN2800.JPG は web ページへの URI で，http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/DSCN2800.JPG が画像ファイルの URI です．「?」が入るか入らないかの違いです．例としてはどうかと思いましたが，ぼくのところのシステムがそうしちゃっているんで．

これで，RSS 2.0 なら，title や descripton や dc:creator や dc:rights は，link 要素が示すリソース，この場合は web ページについてのメタデータになるんです．ところが，pheed として拡張した場合は，title や descripton や dc:creator や dc:rights は，photo:imgsrc で示す画像ファイルのメタデータになるわけです．なんかここらへんがあいまいなんぢゃないかと思います．

RDF で記述するともっと明確ですね．サムネイル画像は FOAF ボキャブラリにもあって，foaf:thumbnail になります．

<foaf:Image 
  rdf:about="http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/DSCN2800.JPG">
    <dc:title>出発の朝</dc:title>
    <dc:description>駅から出発です．</dc:description>
    <dc:rights>Copyright 2003 ONO Hiroki</dc:rights>
    <foaf:thumbnail 
      rdf:resource="http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/thumbnail/DSCN2800.JPG"/>
</foaf:Image>

RDF だと，dc:title や dc:descripton は，foaf:Image の rdf:about が指し示している画像ファイルについてだということが明確です．

そして RSS 1.0 なら，item 要素はこんな感じになるんぢゃないでしょうか．

<item 
  rdf:about="http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/?DSCN2800.JPG">
    <link>
    http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/?DSCN2800.JPG
    </link>
    <title>出発の朝</title>
    <description>駅から出発です．</description>
    <foaf:Image 
      rdf:resource="http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/image/DSCN2800.JPG"/>
    <foaf:thumbnail 
      rdf:resource="http://onohiroki.cycling.jp/PhotoAlbum/2003-09-27_MinamiAizu/thumbnail/DSCN2800.JPG"/>
</item>

画像ファイルのメタデータを XML ファイルとして別に用意するというのは，まだいろんな案があるっていう段階のようですね．検索エンジンなどで検索しやすいようにという意味では pheed は RDF での記述に比べたらちょっと弱いのではないかと思います．RSS をさまざまなメタデータを組み合わせて提供するコンテナとして使う方法にはぼくはとても興味があります．pheed も RSS を使うというところが面白いと思います．

pheed でもかまわないから，メタデータを提供する方法が早くメジャーにならないかな．

TrackBack

SSI と CSS

SSI は，WWW サーバが文書を配信する時に，文書に加工してから送信するっていう技術です．もう，ぼくはこれを使いまくりです．

たとえばぼくの Web サイトでは，ほとんどのページの一番上にメニューがあるけど，あれって，メニューだけ書いた小さなファイルがあって，SSI によって，読み込んで表示しているんです．フレームなんてダサイものを使わなくたって，そういう事ができるんですよ．

@nak さんが SSI を使って Web ブラウザによって異なる CSS を読み込ませるってことをやりはじめたそうです．Javascript 使うと，Javascript をオフにしちゃえば意味ないってことになるのに対して，SSI でやれば，必ず効きますから．

• CSS切り替え / Column@nak
  http://www.atnak.com/blog/archives/000045.html

でも @nak さんは現在のところ，HTML の中で SSI を使って，Web ブラウザによって異なる CSS を読み込ませようとしているようですね．

ぼくは CSS に SSI を適用して，Web ブラウザによって異なる内容を読み込ませています．こうすると HTML 文書がわで作業しないで，CSS 側で作業できるから．

たとえば新しい Web ブラウザへの対応を追加する時に，沢山の HTML 文書に記述を追加するか一つの CSS に記述を追加するかの違い．

ぼくが疑問に思うのは CSS を送信するような CGI を書けば簡単なのに，なんでみんな扱いが大変そうに見える Javascript なんかを使うのかってところ．今時 CGI も使えないようなレンタルサーバサービスはやめちまえって感じです．

ぼくが CGI でなく SSI を使っているのは，CGI で書くよりは SSI で使ったほうが，簡単だと思ったからです．今から思えばどっちもどっちな気がするけど，必要になったらその都度 CSS ファイルを新しく書くのだったらやっぱり SSI を使った方が楽だと思います．

この話題は 2003 年 6 月 13 日にも話題にしました．

• WWW ブラウザによって異なるスタイルシートを適用する方法

TrackBack

写真とメタデータ

単に画像を web で公開するんぢゃなくて，その画像についてのメタデータも web で公開してきたい．どうやってメタデータを用意すればいいのか．そういう問題に対して，ぼくなりにいろいろ調べたり考えたりして，実験しているのが，「SwPhotoAlbum / 画像アルバム」なのです．

メタデータを RDF として提供する実験です．

Perl とかシェルスクリプトとか XSLT などを使って，HTML 文書と RDF め多データをなるべく自動的に生成できるようにってがんばっています．

新しく先日の東京・南会津サイクルトレインの時の画像を公開しました．

プログラムをあちこち書き換えたので，古いものも作り直しました．

TrackBack

あぶりだし / img 要素の alt 属性

Winodws の Internet Explorer などの WWW ブラウザで，画像の上にマウスカーソルを持って行った時に img 要素の alt 属性に文字列を入れておけば，その文字列が表示されるという機能について．吉田さんの蒼風 10 月 2 日付けで話題にしていました：

確かに写真の上にカーソルを持っていくと出てくる文字はあぶり出しのような感じかもですね。

引用終わり．

微妙に時間差があるから，あぶりだしっていう表現は，あっていそうな感じでおもしろいですね．で，どうやって HTML を書いているかについて，突っ込み：

<img align="right" src="image/20031001_morning.jpg" 
 alt="朝家の窓から見た風景" 
 width="160" height="120">

こりゃだめでしょう．alt 属性は，画像の代替なんです．画像を表示しない環境とか，音声読み上げの環境では，画像が表示されるかわりに alt 属性に設定した文字列が表示されたり読み上げられたりします．だから，alt 属性に書いてある文字列は，まわりの文章と続けて読み上げたときに，自然につながらないと駄目ですよ．

ならどうするべきか．これは簡単．以下のようにしてみてはどうでしょう．

<img align="right" src="image/20031001_morning.jpg" 
 alt="" title="朝家の窓から見た風景" 
 width="160" height="120">

title 属性に文字列を指定しても，Winodws の Internet Explorer では，同じように"あぶり出し"つまり文字が吹き出しの用にホップアップされるはずです．alt 属性は，img 要素の必須属性なので，削ってしまうと HTML4 でも XHTML でも文法エラーです．だから alt="" とします．こうして積極的に画像のかわりに置き換える文字列は無しと指定するのです．

こういう事って，決して難しい事ではないはず．

この alt 属性が画像の置き換えだと分かれば，alt 属性に画像ファイル名を入れてみたり，"タイトルロゴ" なんて入れるのが明確な間違いだというのも理解できますね．

で，吉田さんの蒼風の場合で，もし alt 属性を積極的に使うなら，ぼくならこうするな：

<p>
05:30 起床。
</p>
<img align="right" src="image/20031001_morning.jpg" 
 alt="窓の外はまだ明るくなりきらず、早朝の静かさが残っている。" 
 title="朝家の窓から見た風景" 
 width="160" height="120">
<p>
酔っ払った次の日は怪しく早く目覚めることがあるけど、今日はそれだな。
昨夜お風呂に入らなかったからゆっくり朝風呂に入ろう。
</p>
<p>
朝ごはんは、梅おにぎり二つ、卵とにらのお味噌汁、焼いた塩鮭、キャベツの千切り。
</p>
<p>
<img  src="image/20031001_tukinro.jpg" 
 alt="通勤の途中で公園を通り抜けて会社へ。"
 title="通勤の途中で通り抜ける公園" 
 width="160" height="120">
</p>
<p>
朝一で解析依頼が舞い込んでいるよ…。
</p>

これはちょっと強引かな．でもテキストの部分と alt 属性の文字列を順番に読んで行って，文章としておかしくない状態なら alt 属性がうまく機能しているという事です．この時 title 属性の文字列は無視します．title 属性の文字列は画像の代替ではないからです．
いずれにしても alt="" で，title 属性を使うようにすれば，挿絵的に画像を使う分には問題ないです．

TrackBack

2003 年 9 月のアクセス統計発表

先月 1 ヶ月間のおのひろきおんらいんのアクセス統計です．8 月と比べると微妙にアクセスが若干減少しています．オレゴンに出かけている間は更新停止だったけど，それほど減りませんでした．

• おのひろきおんらいん全体で 172,149 ページビューで 8 月の 176,334 から若干減少
• welcome ページは 26,786 ヒットで 8 月の 27,478 ヒットより若干減少
• 1 日あたりの訪問者数は平均 1,948 で，これに関しては，8 月の 1,914 よりもちょっと増えました．

今月の注目すべき異変は RSS の利用が増えたことです．"履歴もしくは日誌" としてつらつら書いているものの，RSS を http://onohiroki.cycling.jp/info/weblog.rdf として公開していますが，これのアクセスが急激に増えました．

実に 2.5 倍ほどに増えていますし，9 月の 2471 ヒットという数値は，他のページと比較しても，14 番目に多いアクセスでした．Myblog.jp というサービスから RSS のアクセスがあったり，RNA のような RSS を扱ういわゆるアンテナのようなサービスができて，RSS の利用のされ方にも広がりが出てきたことも要因の一つかと思います．

TrackBack