2005 年 7 月の履歴(もしくは日誌)


2005 年 7 月

7 月 28 日

チェーンメールを知っていますか?

チェーンメール」って知っていますか? きちんとチェーンメールのことを知っていて,どうしてチェーンメールの転送がいけないのかをきちんと説明できる人は少ないと思います.チェーンメールには不幸の手紙のような内容のいたずらのものが多いのですが,中にはいたずらでなく病気の人を助けようと情報を探したり助けを求めたりする内容のものもあります.

不幸の手紙のような内容のいたずらのチェーンメールがなぜいけないのかを,例えば小学生や中学生に適切な言葉を使って説明できるでしょうか? 実は今,電子メールが若年層に広がるにしたがって,いたずらのチェーンメールが若年層で繰り返し流行する事態になっています.ぼくは「チェーンメールは悪」と題した Web ページでチェーンメールについての情報を公開していたのですが,ここ数年になって,中学生や高校生と思われるような若い人からの相談のメールがかなり増えて来ています.ぼくは 1 件 1 件のメールに対して,なるべく分かりやすい言葉でチェーンメールのことを説明し,また気味の悪いいたずらのチェーンメールにおびえる必要は無いのだということを繰り返し説明して来ました.学校教育や家庭内での教育でもチェーンメールについてきちんとした説明をしてもらいたいのですが,実際にはうまく説明できる大人があまりいないのではないでしょうか.

また,中学生や高校生,場合によっては小学生からの質問に対して,丁寧に対応できる窓口が見当たらないようなのです.

財団法人 日本データ通信協会がチェーンメール送信先のメールアドレスを用意したというニュースが今月上旬に流れました.

その携帯用チェーンメール転送先のページには以下のような文言がありました:

チェーンメールは、受け取っても他の人に送らないことが基本ですが、転送しない場合に直接の危害が及ぶ内容など、送らないと不安が大きい場合があります。

そこで、当協会では、携帯電話のチェーンメール用に、10個の携帯電話メールアドレスを準備しました。

チェーンメールを送らなければどうしても不安な場合は、ここに転送してください。

こんな事をしていてはチェーンメールの転送が良くないということを説明できません.ですからチェーンメールを転送するかしないかという判断基準が育たないのです.判断基準が無いままでは,結局失敗をすることになってしまいます.チェーンメールにはいたずらのものだけではなく,善意から始まる嘘ではない内容のものもあるからです.

やはり今月,会員制の Web コミュニティサイトである mixi 内で「病気についての情報を求めている」という内容の文章を日記に掲載し,その文章をコピーしてあなたの日記に貼付けてくださいということを始めた為に,メールの転送ではなく日記の文章を転載という形ではあったけれども,ちょうど善意から始まったチェーンメールのパターンと同じパターンをたどったようです.

善意から始まるチェーンメールのパターン:

  1. 病気や被災などなにかしら困っている人がいます.その本人ではなく,また直接の知人でもなく,知人の知人くらいの人からチェーンメールが始まることが多いようです.その内容は困っている人になにかしてあげたい.このメールを皆に転送して沢山の人に広めて,「なにかしてあげたい」を広めようというような内容になります.具体的な行動を要求する場合もあるし,適当な人や情報を探しているという場合もあります.
  2. チェーンメールを始めた人から,あまり遠くない知人の知人のまた知人といった範囲で広まり始めます.
  3. 一定の時間を過ぎると爆発的にもとのメールのコピーが出回るようになります.
  4. それは「チェーンメール」だから転送をやめろと指摘する人が現れます.この時に,チェーンメールを理解していない人が多いので,もともとの情報は本当なのかデマなのかという事が問題になります.
  5. もともとの情報が本当かどうか確かめようという動きが出て来ます.連絡先等が明記してある場合は,そこに連絡が殺到します.連絡先がメールであれば受信容量がいっぱいになってメール受信ができなくなったり,Web サイトがあれば,転送容量の超過でサーバがダウンする場合もあります.いずれにしても連絡先にかなりの負荷がかかります.連絡先がチェーンメールの発信元ではなく,チェーンメールとは直接関係ない公的機関(例えば病院とか)だったら,問い合わせ先に重大な迷惑をかけることになりかねません.
  6. 送信したメールがエラーで帰って来たからデマだったのだとか,参照すべき Web サイトが存在しなかったからデマだったのだといった,嘘にだまされたという誤解した意見が大きくなります.またコピーして転送されていた内容に途中で誤情報が紛れ込んだりしてなにが本当なのか判断するのが難しくなります.
  7. しばらくしてそのチェーンメールの転送の流行が終わりますが,関わった多くの人は,それが本当の話だったのか嘘だったのかを把握できないままです.また,関わった多くの人はチェーンメールとは何なのか,なぜチェーンメールの転送がいけないのかを理解しないままです.

善意から始まるチェーンメールは,大体がこんなパターンになると思います.結局,多くの人がチェーンメールについて無知なので,どうしてもこのような事になってしまうのですね.

今,チェーンメールというキーワードで Web を検索すると,多くの Web サイトがヒットしますが,大抵はチェーンメールを紹介するような内容の Web サイトで,場合によってはおもしろいチェーンメールというのを紹介することがその Web サイトのネタになっていたりします.

残念なことに,そのような Web サイトで紹介されたチェーンメールを模倣したり,もしくはそのままコピーして,いたずらのチェーンメールを初めている輩もいるようです.

もっとチェーンメールの事をきちんと説明した Web サイトが増えるといいのですが...

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050728n2 TrackBack

Hatena ID Auto-Discovery について

303 リダイレクションで他のページに転送さえる URI を dc:creator で指し示すことが可能な URI として用意しておいて,そこからはてなのユーザ ID を得るというのは,ココログのアカウント名を書きたくてもココログが対応した URI を定義してくれないといけないっていうところで,あまり汎用性のないやりかたなのかなって思いました.最初に提案があったときはいいなって思ったのですが,やっぱり良くないなぁ.Trackback ping URI の場合のように記事にコメントとして埋め込む RDF の中でFOAFを用いて記述する方法が検討されていますが,これも気になる点があります.

どうも「単純にはてなのユーザ ID を知りたい」というだけの目的に対して,それをそのまま ユーザ ID を記述しようとするから複雑な話になっているように思います.「投げ銭」のための URI を用意してそれを示すようにすれば foaf:tipjar を使ってもっと単純に記述できて,他のサービスも同様の記述で応用できて,はてなのユーザ ID も foaf:tipjar の指す URI から簡単に抜き出せるとは思うのですが.それぢゃだめなのでしょうか.

以下,気になるところを少し:

dc:creator の中身を一度 Person でくくって、その中にアカウントを記述していくので、たとえば一人でアカウントを2つもっていても一つの dc:creator 要素で済みますし

これは dc:creator の foaf:Person の中に foaf:holdsAccount を 2 つ持てるって意味ですね.

あと Trackback で RDF を HTML/XHTML に埋め込む時に,XHTML にはコメントとしてではなく直接埋め込むことを想定していて,[訂正:現状では DTD 違反になるから[削除:HTML ではそれができないから]]コメントでって話だったと思います.だから Trackback ping URI の埋め込みについての話では RDF の部分が XHTML としてレンダリングした時に値が表示されないように配慮されていました.ぢゃあ実際に XHTML に埋め込む時に,コメントとしてではなく,直接埋め込むかというと DTD との関係で今のところは直接埋め込むことをぼくはしないだろうけど.それで問題の部分は <faof:accountName>naoya</faof:accountName> であって,ここは書き方を変えたほうが良いでしょう.

修正案はこんな:

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:foaf="http://xmlns.com/foaf/0.1/">
<rdf:Description rdf:about="http://tociyuki.cool.ne.jp/hoge.html">
  <dc:creator>
    <foaf:Person>
      <foaf:holdsAccount>
        <foaf:OnlineAccount foaf:accountName="naoya">
          <foaf:accountServiceHomepage rdf:resource="http://www.hatena.ne.jp/"/>
        </foaf:OnlineAccount>
      </foaf:holdsAccount>
    </foaf:Person>
  </dc:creator>
</rdf:Description>
</rdf:RDF>

ちなみに foaf:tipjar を使うとこんな:

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:foaf="http://xmlns.com/foaf/0.1/">
<rdf:Description rdf:about="http://onohiroki.cycling.jp/2005-07-28-1">
  <dc:creator>
    <foaf:Person>
      <foaf:homepage rdf:resource="http://onohiroki.cycling.jp/"/>
      <foaf:tipjar rdf:resource="http://www.hatena.ne.jp/tipjar/onohiroki"/>
    </foaf:Person>
  </dc:creator>
</rdf:Description>
</rdf:RDF>

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050728n1 TrackBack

7 月 24 日

RDF 的な考え方における人の URI は Web ページとして存在しない URI であるべき

作者の情報を HTML/XHTML に埋め込むっていう話題について,神崎さんからその人の「ホームページ」URIとその人自身のURIを混同しそうな気配があるってことで,それについて簡単にまとめた記事があがりました.結論から言うと,ある Web ページの URI が dc:creator の値になるのはおかしいってことで,それと人物に URI を与えるってのは別の話だというわけです.

このとき、人物のURIは必ずしもウェブ上でアクセスできる必要はない。urn:pim:MK705といったURNでもいいし、でなければhttp://www.kanzaki.com/user/masakaなど、ページとしては存在しないhttp:スキームのURIでもよい(このあたりは、httpRange-14の話を参照)。

なるほど.

  • 人物を表す URI は,Web 上でアクセスできる必要はない.
  • ページとして存在しない URI でもよい.

これって結構 RDF によるメタデータの記述の事をまじめに考えないと感覚として身に付かないですね.逆にいうと普通に Web を使っている感覚からすると,かなり普段の感覚と違う印象でしょうか.ページとして存在しない URI でもよいというか,むしろページとして存在する URI を人物の URI にするのが良くなくて,存在しないほうが良いというのは,なかなか身に付かないですね.頭で分かったつもりでいても,何度でも間違えてる...

7 月 22 日の「はてなの「投げ銭」と Dublin Core メタデータの HTML/XHTML への埋め込み」を書き始めた時は 「Hatena ID Auto-Discovery の仕様」をみてなんか違和感があって書き始めたのだけど,途中でなんだか分からなくなってしまったのです.

現行の「Hatena ID Auto-Discovery の仕様」の次の書き方が問題あるとすれば:

<link rel="DC.creator" title="id:naoya" href="http://www.hatena.ne.jp/user?userid=naoya" />

やっぱり下の書き方が無難かな:

<meta name="dc.creator" content="onohiroki, hatena"/>

いずれにしても HTML/XHTML の head 要素の部分に書き換えるってのはかなり敷居が高いから,はてなの「投げ銭」の場合は記事の中で簡単に書けるやり方が本命になるかなぁ.

関連する話:

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050724n1 TrackBack

7 月 22 日

はてなの「投げ銭」と foaf:tipjar

microformats として rel="payment" というのが提案されているらしいです.rel 属性を使う場合は,profile を用意して head 要素に profile を指定するってのが HTML/XHTML の決まりです.microformats として知られている XFN のプロファイルは http://gmpg.org/xfn/11 ですね.rel 属性を利用した microformats でメタデータを埋め込むなら,既存の profile を利用できるようにするか,もしくは profile も同時に定義するかですよね.そしたら GRDDL を利用するなら,既にありものの profile や FOAF などを利用するだけで済みます.

rel="payment" の場合は次のような形が提案されています:

<a href="http://blahblah/payme.html" rel="payment">Pay Me</a>

これと先日ぼくが提案したものはあまり変わりないと思います.先日の提案ではこうでした:

<p class="me"><a rel="foaf.tipjar" href="http://t.hatena.jp/naoya/tipjar">投げ銭よろしく</a></p>

rel="payment" か rel="foaf.tipjar" かの違いですね.profile を定義しないならどっちでもまったく同じ事になります.

神崎さんが用意した profile を利用するなら,a 要素を p 要素でかこって p 要素のクラスに me と指定します.こうすることによって,meta 要素で指定されている著者の情報と繋がるのです.foaf:Person を使うとかなり複雑になってしまうのですが,クラスの属性値 me を使って,head 要素の中に書かれている著者情報と結びつける事で,XHTML では簡単な記述をするだけで,リッチなメタデータが抽出できるようになっています.

<html xmlns="http://www.w3.org/1999/xhtml">
  <head profile="http://purl.org/net/ns/metaprof/">
    <title>記事タイトル</title>
    <meta name="author" content="ONO Hiroki" />
    <link rev="made" href="mailto:onohiroki@cup.com" />
    <link rel="schema.foaf" href="http://xmlns.com/foaf/0.1/" />
  </head>
  <body>
    <p class="me"><a rel="foaf.tipjar" href="http://t.hatena.jp/naoya/tipjar">投げ銭よろしく</a></p>
  </body>
</html>

この XHTML を profile で指定された XSLT スタイルシートで RDF/XML に変換すると下のようになります:

<rdf:Description rdf:about="">
  <dc:title>記事タイトル</dc:title>
  <foaf:maker>
    <foaf:Person rdf:nodeID="me">
      <foaf:mbox rdf:resource="mailto:onohiroki@cup.com"/>
      <foaf:name>ONO Hiroki</foaf:name>
      <foaf:tipjar rdf:resource="http://t.hatena.jp/naoya/tipjar" rdfs:label="投げ銭よろしく"/>
    </foaf:Person>
  </foaf:maker>
</rdf:Description>

はてなの「投げ銭」を実現する時には,「投げ銭」のページを用意して,それへのリンクを作り,さらに microformats としてメタ情報を加えるのであれば,rel 属性の値は,foaf.tipjar も認める方向だとうれしいな.payment か tipjar もしくは foaf.tipjar と記述するってのでいいのでは?

これなら「投げ銭」のための一般的な仕組みになり得ますね.

あと,はてなの「投げ銭」を実現する場合には foaf:tipjar が指すのに適切な,「投げ銭」のページが用意されるとうれしいです.きっと獲得ポイント数を表示するかしないかの設定ができたり,はてなの「投げ銭」の説明と,だれに対して「投げ銭」なのかを説明してあるページになるでしょうね.

ちなみにここでの「投げ銭」ってのは,Web でなにか良い事を書いた人に対して,読んだ人が何かしらの方法で「チップ」を支払う方法の事です.はてなの場合は,はてなのポイントで実現しようとしているそうです.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050722n2 TrackBack

はてなの「投げ銭」と Dublin Core メタデータの HTML/XHTML への埋め込み

さてはて,naoya さんの はてなの「投げ銭」サービス実現の為に,はてなの外のあるページと,その書き手のはてなの ID をどうやって関連づけるかという話題ですが,HTML/XHTML の head 要素の中の meta 要素か link 要素にメタデータを埋め込む方向で進んでますね.

meta 要素の場合は,文字列が値に,link 要素の場合は,URI が値になります.

ですから ID そのものを値にするなら meta 要素ですし,あるページの URI を値にするなら link 要素ですね.

kota さんの提案では,Dublin Core メタデータの creator を利用して値には,はてなのページの URI を示すようにしています.

Dublin Core の creator が link 要素で URI を値に持つよりは meta 要素で文字列の値を持つ方が自然に感じます.

<meta name="dc.creator" content="onohiroki, hatena"/>

で,Dublin Core の creator の定義はどうかというと以下のように定義されています.

Term Name:
creator
URI:
http://purl.org/dc/elements/1.1/creator
Label:
Creator
Definition:
An entity primarily responsible for making the content of the resource.
Comment:
Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.

まぁ,値として「人」や「サービス」を持ち得て,その人だかサービスの URI を示すってことで link 要素でも良いのかなぁ.

指し示す URI の先が作者のプロフィールを表示する http://d.hatena.ne.jp/onohiroki/about だったらより自然かと思いました.はてなダイアリーのプロフィール表示ってはてなダイアリーを利用している人しかないのですよね.

でも http://www.hatena.ne.jp/user?userid=onohiroki っていう URI の指し示す先は,そのユーザの人力検索はてなでの質問回答履歴になるので,質問回答をしていうる人に対しては,はてなダイアリーのプロフィール表示よりもその人を良く表しているのかもしれないですね.これはこれで良いかも.

ちなみに Doublin Core の HTML/XHTML 埋め込みでは <head profile="http://dublincore.org/documents/dcq-html/"> と head 要素で profile を指定することが決められています.

さらに,name 属性や rel 属性の値は,大文字小文字は無視しろとありますね.だから <meta name="DC.creator" content="onohiroki, hatena"/> も <meta name="dc.creator" content="onohiroki, hatena"/> も同じものとして扱う事になります.これは,「Hatena ID Auto-Discovery」の実装でもきちんとそうして欲しいと思います.

最終的には,他のサービスでも流用できるような汎用性のある形が決まって,普及するといいですね.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050722n1 TrackBack

7 月 19 日

そのページが誰のものなのかを示す識別子を埋め込む方法

最初に識別子(ID)を埋め込む方法について検討し,つぎに「投げ銭」についても考えてみます.

まず,そのページが誰のものなのかを示す識別子を埋め込む方法を考えてみます.もし FOAF を利用するのであれば,FOAF で ID を記述するか,もしくは ID が特定できる URI をもつページが自分のものであると記述しておいて,そこから ID を探すというのはどうでしょう.そうすれば,ある記事の持ち主の ID を探すとなると,ある記事に対して FOAF Autodiscovery を利用して FOAF を特定し,その FOAF から ID を探すという手順になります.

ID が特定できるあるページが自分のものだと記述する場合:

<foaf:Person rdf:nodeID="me">
  <foaf:made rdf:resource="http://t.hatena.jp/naoya/tipjar" />
</foaf:Person>

ID を直接記述する場合:

<foaf:Person rdf:nodeID="me" xmlns:hatenaid="http://ns.hatena.ne.jp/hatenaid#">
  <hatenaid:hatenaid>naoya</hatena:hatenaid>
</foaf:Person>

FOAF を利用できるようになっている Weblog サービスもあるけど,直接 FOAF を編集したりできないだろうし,実現は難しそうです.同様に Weblog サービスを利用していたら XHTML の head 要素の中の meta 要素などを応用するのも難しいのではないでしょうか.やっぱり記事の XHTML の中に情報を埋め込む事を考えてみます.

ID が特定できるあるページが自分のものだと記述する場合:

<p class="me"><a rel="foaf.made" href="http://t.hatena.jp/naoya/tipjar">naoya</a></p>

ID を直接記述する場合:

<link rel="schema.hatenaid" href="http://ns.hatena.ne.jp/hatenaid#" />
<p class="me"><span class="hatenaid.hatenaid">onohiroki</span></p>

この ID を XHTML に埋め込む場合は,神崎さんの XHTML metainformation profile を利用すれば,GRDDL を利用して RDF/XML としてメタデータを抽出できます.集出した結果は,先にあげた FOAF のようになります.XSLT スタイルシートが用意されているので簡単に試す事ができます.

もっとも GRDDL を利用しなくても XHTML に埋め込まれれているのから抽出するのはいろいろ方法はあるでしょうね.

これらのどちらも Web ブラウザで何かしらが表示されてしまいますが,それが無意味な表示になるのは避けたいところです.

この話のもとは,「naoyaのはてなダイアリー - そのページが誰のものなのかを示す識別子を埋め込む仕様を考えています」という記事なのですが,ここでは「そのページが誰のものなのかを示す識別子を埋め込む仕様」が問題になっていますが,その理由は「投げ銭」のサービス実現に向けての話のなかで出てくるのです.投げ銭ってのは,つまり良い記事を書いた人にチップを与えるって事です.

はてな側で,それぞれのユーザの ID で「投げ銭」のことを説明するページを用意したらどうでしょうか.そして,それぞれの記事からそのページにリンクしてもらうのです.それならそれがどういうリンクなのか明確ですし,そのリンクの URI からはてなの ID を簡単に拾えそうですよね.

http://d.hatena.ne.jp/naoya/about だと,プロフィールのページになりますが,そんな感じで http://t.hatena.jp/naoya/tipjar っていうページを作って,そこで投げ銭についての説明等が参照できるようにします.

で,FOAF でも tipjar についてのページを記述する foaf:tipjar ってのがあるのでそれを使えばこうなります:

<p class="me"><a rel="foaf.tipjar" href="http://t.hatena.jp/naoya/tipjar">投げ銭よろしく</a></p>

なにか画像を作っても良いですね:

<p class="me"><a rel="foaf.tipjar" href="http://t.hatena.jp/naoya/tipjar" title="はてな投げ銭" ><img src="tipjar.png" alt="投げ銭よろしく" /></a></p>

これを GRDDL で RDF/XML に変換すれば:

<foaf:Person rdf:nodeID="me">
  <foaf:tipjar rdf:resource="http://t.hatena.jp/naoya/tipjar" />
</foaf:Person>

ってなるわけです.どうでしょう?

急いで書いたので,あまり分かりやすくは書けていないのは申し訳ない.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050719n1 TrackBack

7 月 15 日

はてなの RSS (RDF/XML) には,いつもがっかり

Google Maps API はすごいですね.これを利用したものがいろいろ出て来ていますが,「はてなマップ」なんてのも出て来ました.それで位置情報を含んだ RSS を RSS 1.0 形式で配信するようになったんだけど,それは RDF/XML としてちょっとおかしいです.「はてなフォトライフ」の時も残念な RSS でしたが,また残念な RSS になってます.RDF/XML としてきちんとした RSS 1.0 を配信するか,それができないなら RSS 1.0 ぢゃなくて RSS 2.0 とかを利用するかのどちらかにしてほしい.やっていることがめちゃくちゃですよ.Google Maps API などの外のオープンなものは利用するけど,RDF/XML などのオープンな規格については,どーでもいいっていう態度に見えますぞ.

今のところ,こんな感じの RSS が配信されています.注目している rss:item だけ抜き出して,さらに関係ない要素を省略します:

<item rdf:about="http://f.hatena.ne.jp/tiga/20050708143637">
  <link>http://f.hatena.ne.jp/tiga/20050708143637</link>
  <hatena:imageurl>http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637.jpg</hatena:imageurl>
  <hatena:imageurlsmall>http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637_m.jpg</hatena:imageurlsmall>
  <geo:lat>35.6510</geo:lat>
  <geo:long>139.6938</geo:long>
</item>

これ経度と緯度といった位置情報がなんの位置情報なのかという点をまったく意識していないで書いていると思うのです.RDF ってのは,メタデータを記述するのですが,「主語」がなにかってのが重要です.位置情報を記述するだけでなくて,「なにの」位置情報なのかってのですね.

で,なにの位置情報なのかを考えて文章かします:

    • 「記事 (http://f.hatena.ne.jp/tiga/20050708143637)
    • 「主題 (foaf:topic) として」
    • 「写真 (http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637.jpg) がある.」
    • 「写真 (http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637.jpg)
    • 「主題 (foaf:topic) として」
    • 「ある地点 (geo:Point) がある」
    • 「ある地点 (geo:Point)
    • 「緯度 (geo:lat) は」
    • 「35.6510 である.」
    • 「ある地点 (geo:Point)
    • 「経度 (geo:long) は」
    • 「139.6938 である.」

これを RDF/XML にしたら:

<item rdf:about="http://f.hatena.ne.jp/tiga/20050708143637">
  <link>http://f.hatena.ne.jp/tiga/20050708143637</link>
  <foaf:topic>
    <foaf:Image rdf:resource="http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637.jpg">
      <foaf:thumbnail rdf:resource="http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637_m.jpg" />
      <geo:Point>
        <geo:lat>35.6510</geo:lat>
        <geo:long>139.6938</geo:long>
      </geo:Point>
    </foaf:Image>
  </foaf:topic>
</item>

これ,出発点を記事にしているけど,画像ファイルを出発点にした方がより簡潔でしょう.

<item rdf:about="http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637.jpg">
  <link>http://f.hatena.ne.jp/tiga/20050708143637</link>
  <foaf:Page rdf:resource="http://f.hatena.ne.jp/tiga/20050708143637" />
  <foaf:thumbnail rdf:resource="http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637_m.jpg" />
  <foaf:topic>
    <geo:Point>
        <geo:lat>35.6510</geo:lat>
        <geo:long>139.6938</geo:long>
    </geo:Point>
  </foaf:topic>
</item>

foaf:topic 以下は rdf:parseType を使って簡略化する方法があります:

<foaf:topic rdf:parseType="Resource">
  <geo:lat>35.6510</geo:lat>
  <geo:long>139.6938</geo:long>
</foaf:topic>

そうでなかったらこんなでも良いと思います:

<foaf:topic>
  <geo:Point geo:lat="35.6510" geo:long="139.6938" />
</foaf:topic>

で,最初のはてなの RSS を RDF/XML として書きなおすと:

<item rdf:about="http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637.jpg">
  <link>http://f.hatena.ne.jp/tiga/20050708143637</link>
  <foaf:page rdf:resource="http://f.hatena.ne.jp/tiga/20050708143637" />
  <foaf:thumbnail rdf:resource="http://f.hatena.ne.jp/images/fotolife/t/tiga/20050708/20050708143637_m.jpg" />
  <foaf:topic>
    <geo:Point geo:lat="35.6510" geo:long="139.6938" />
  </foaf:topic>
</item>

ほら,見た目の複雑さは大した違いはないですよね.

FOAF っていうと,みな「知人ネットワークを表現する...」ってのを最初に思い浮かべると思うけど,実は RDF/XML の基本ボキャブラリとしてとても広く使える便利なものなのです.hatena:imageurlsmall なんてのはやめて foaf:thumbnail を使えば良いと思うし,geo ボキャブラリを使うなら,きちんとそれが何の位置情報なのかも考えた記述をしてほしいです.RDF としての意味を考えることができないなら RSS 1.0 をやめて RSS 2.0 にしたら良いと思います.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050715n1 TrackBack

7 月 6 日

トラックバックに失敗しました

なぎのさんが,こっちへのトラックバックに失敗したそうです.405 Method Not Allowed というエラーメッセージだったそうですが,いったい何が起こったのでしょうか? なぎのさんは「はてなダイアリー」を使っています.トラックバックをするときには,相手の記事の URL ではなく「トラックバック URL」が必要です.はてなダイアリーでは記事の URL がそのままトラックバック URL になっていますが,他の Weblog では記事の URL とトラックバック URL が異なるのが普通です.この「おのひろきおんらいん」でも記事の URL とトラックバック URL は異なります.

例えばこの記事の末尾に「Trackback」っていうリンクがあり,それをクリックするとトラックバック ピン送信画面になります.そこの画面上のほうに「この記事のトラックバック URL:http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050706n2」って書いてあると思います.これが「トラックバック URL」です.もしくは記事の下側にそのまま書いてある場合もあります.(表示の仕方によって違うのです.)

これをはてなダイアリーの編集画面の「トラックバックURL」っていう入力欄に入力してください.それで記事を更新すればトラックバック ピンが送信されます.

間違った URL を入力すると次のような表示がでるみたいです:

http://onohiroki.cycling.jp/ へのトラックバックに失敗しました。 (405 Method Not Allowed)

これは入力したのがトラックバック URL ではないからです.

きっとはてなダイアリー使っている人で,はてなダイアリーの外にトラックバックを送った事がない人って沢山いるに違いないと思います.

はてなダイアリー内部では,リンクすると自動的にトラックバック相当の動作をするのですが,はてなダイアリーの外にトラックバックする場合は,上記のような手順をふむ必要があります.

想定するこの記事の読み手:
はてなダイアリーを使っていて,ぼくとは自転車繋がりで,特にこの手の話に詳しくないけど,「トラックバック」っていうキーワードを聞いた事がある人.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050706n2 TrackBack

自転車でのヘルメット着用のすすめ

ぼくは自転車に乗る時はヘルメットをかぶるようにしています.皆さんにもお勧めします.自転車に乗る時にヘルメットがどうして必要なのか分からない人もいるでしょう.また必要なのは分かっているけど,ヘルメットをかぶって自転車で走る自分の姿に自信が持てなくて躊躇している人もいるでしょう.そのような人にも平等に事故に遭遇する確率が割り当てられている訳ですが,「その時」にこそヘルメットをかぶっていることを願っています.

さてはて,アクセスログを見ていて,ぼくの自転車のヘルメットについてのコンテンツにリンクしてくださっているページを発見しました.その人の事故体験を語っている Web ページです.前輪パンクをきっかけに転倒したようなのですが,血で汚れたヘルメットの写真などを掲載しつつ,その事故の体験とヘルメットについての考えが語られています.

事故した時にヘルメットをかぶっていたから助かったという経験談と,ヘルメットしていなかったけど生還したという経験談は,探せば出てくると思います.でもね,でもね,死んでしまった人による経験談はありえないし,事故をきっかけに自転車に関わりが無くなった人の経験談もなかなか探せないと思います.

必要なのは分かっているけど,ヘルメットをかぶって自転車で走る自分の姿に自信が持てなくて躊躇している人は,ヘルメットかぶってサイクリングしている人と一緒に走る機会が増えると変わってくると思うのです.毎月第 3 日曜日に荒川サイクリングロードで集まって走っているので,それに参加してもらうと良いかも.全員がヘルメット着用ってわけでは無いですが,ヘルメットをかぶっている人は多いです.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050706n1 TrackBack

7 月 5 日

2005 年 6 月のアクセス統計発表

一年ぶりにアクセルログの解析をしました.前回は2004 年 6 月分です.その発表のあとでサーバクラッシュが発生して,アクセスログしていませんでした.アクセス解析に用いているのは Webalizer です.以前とはちょっと設定が違っています.

  • おのひろきおんらいん全体で 306,422 ページビューで,昨年 6 月の 208,394 ページビューより増加
  • welcome ページは 61,721 ヒットで,昨年 6 月の 33,794 ヒットより増加
  • 1 日あたりの訪問数は平均 2,722 で,昨年 6 月の 2,313 より増加
  • 履歴もしくは日誌の RSS は 39,763 ヒットで,昨年 6 月の 20,860 ヒットより増加

RSS は大きく伸びていますね.全体のページビューよりも,Welcome ページのヒット数の方が伸びが大きいのは,最近は「履歴もしくは日誌」ばっかり更新していて,単独ページのコンテンツがあまり増えていないからでしょうか.1 日あたりの訪問数も鈍い動きです.つまり同じ人が何度も Welcome ページや RSS をチェックしてくださっているという事か.

ひさびさに検索キーワードを調べてみたら,意外な結果が出てました.

アクセスログ解析による検索文字列
ヒット数検索文字列
1002チェーンメール
941折りたたみ自転車
837リカンベント
549bd-1
320折り畳み自転車
310ハブダイナモ
305おのひろき
180pscマーク
165bike friday
159チェーンメールとは
118PSCマーク
114麦草峠
113自転車
112ダイナモ
110タンデム

チェーンメールについて検索してやってくる人が意外に多そうです.チェーンメールについてのページのアクセスは 2,946 ヒットであり,その中の約 1/3 が検索エンジンから直接やって来ていることになります.検索してやって来る率がとっても多いのですね.折りたたみ自転車のページへのアクセスが 5,095 ヒットに対して検索エンジン経由が 1,261 ヒット,リカンベントのページが 3,182 に対して 837 ヒットです.自転車関連等のページは Web サイト内部のリンクや外部からのリンクが多いのに,チェーンメールのページは,検索エンジンからの訪問が多いのですね.そろそろ独立したサブドメインを用意して,Yahoo! Japan などへの登録を目指そうかな.

「折りたたみ自転車」と「折り畳み自転車」では,前者のほうがキーワードとしてよく使われているということが以前の調査で分かったので,その昔に「折りたたみ自転車」でも検索エンジンでヒットするように小手先の検索エンジン対策を行いました.その効果が出ているとも言えなくもないですが,実際には両方のキーワードで検索した時の順位がかなり落ちているのです.自転車関連コンテンツの更新があまり無いので当然です.小手先の対策などその程度のものですな.

今月の反省:
チェーンメール関連のコンテンツの独立は,そろそろまじめに考えよう.
自転車関連のコンテンツに期待してやってくる人はそれなりにいるんだから,まじめに更新しよう.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050705n2 TrackBack

DoubleDay Recumbent Tandem が中古で売りに出されています

Bike Friday の折りたたみのリカンベントタンデムである DoubleDay が中古で売りに出されています.なぎのさん,買いませんか? 送料別で $4,000 ですって.安い!?

DoubleDay って,後ろに乗るハンドル操作をしないストーカのシートは一段低くなっているのですが,ハンドル操作をするキャプテンに比べて,ストーカの重心が低くなるのは運転しやすそう.そのほうがキャプテンはバランスとりやすいのです.実際に Bike Friday で DoubleDay に試乗してみた時も,とても運転しやすいと思いました.

DoubleDay はすでに生産されていないので欲しければ中古を買うしかありません.なぎのさん,まえから欲しいて言ってましたもんね.

なぎのさんが買ったら乗せてください.お願いします.

http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050705n1 TrackBack

[ 上に戻る]