|
|
|
|
|
||
|
||
昨日書こうと思っててすっかり忘れてたことを。はてなだけではなく、別のアカウント情報をAutodiscoveryにて埋め込む方法と、注意点についてです。
Account Autodiscoveryの仕様がまとまってはてなポイントを贈るなんてページができたのはいいんですが、複数のアカウントを記述する方法が書かれていないんですよ。これだとはてなの外にこの仕様が広がらないので、なんか面白くありません。というわけでここに書いてみます。
とりあえずソースをごらんくださいな。
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <rdf:Description rdf:about="http://example.com/permalink"> <foaf:maker rdf:parseType="Resource"> <!-- ひとつめ --> <foaf:holdsAccount> <foaf:OnlineAccount foaf:accountName="kotastyle"> <foaf:accountServiceHomepage rdf:resource="http://www.hatena.ne.jp/"/> </foaf:OnlineAccount> </foaf:holdsAccount> <!-- ふたつめ --> <foaf:holdsAccount> <foaf:OnlineAccount foaf:accountName="kota"> <foaf:accountServiceHomepage rdf:resource="http://example.com/"/> </foaf:OnlineAccount> </foaf:holdsAccount> <!-- みっつでもよっつでもいつつでも --> </foaf:maker> </rdf:Description> </rdf:RDF>
というわけで、複数のアカウント情報を記述する場合には、foaf:holdsAccountのブロックをアカウントの数だけfoaf:makerに用意しなければなりません。
「なんでふたつのfoaf:OnlineAccountを、一緒にひとつのfoaf:holdsAccountに入れられないのか」という疑問を持った方、するどいです。でもだめなんです、XML的には不思議じゃないんですが、RDF的に困るのです。
具体的な説明をすると混乱する人しか出ないような気がするので、ちょっとつっこんで理解したい方は、神崎先生の書かれた複数の知人を示すときの注意点をお読みください。文中のfoaf:knowsをfoaf:holdsAccountに、foaf:Personをfoaf:OnlineAccountに読み替えると、疑問への答えとなりますので。
というわけで、アカウントの数だけfoaf:holdsAccountを記述してください。Autodiscoveryを解析して実装する方々も、この点に関してはご注意を。
そうそう、先ほどの例は僕が一番スマートに思うものを書いたのですが、実はアカウントの数だけrdf:RDFなブロックを記述しても、意味的におかしいところはないのですよ（実装がどうなのかは知りませんが）。ただ、面倒なので複数のfoaf:holdsAccountでAutodiscoveryを記述するのをおすすめしたいです。
はてな側にもこれをどこかに書いておいて欲しいなとおもったり。
RSS 3.0ですって。もうAtomも完成したんで特に騒ぐ気もないんですが、ちょっと面白かったので。
実は3年前の「フィード戦争」の時に、Dave Winerをちゃかそうとテキスト版のRSS 3.0が作られたりしたんですよね。まあネタなんで、RSSのグループに入れてもらってるのを見たことがないんですが。
そういえばRSS 1.0はRDF/XMLを構文として採用してますが、その気になればN3とかTurtleでプレーンテキストのフィードとか作れちゃうんですよね。contentモジュールとかは扱えませんが。
そろそろAtomでみんな妥協しないかい。
さてさて、Account Autodiscoveryの話題が落ち着いたらしいですね。XHTML文書中にそのままRDF/XMLな文を埋め込むのはどうなのかなあと思ったりしますが、まあコメントよりはいいかとも思ったり。
というわけでXHTML 2.0だとどうなるかを書いてみました。ソースを書くのに思ったより時間がかかってしまったので、「説明お願い」とか言われたら詳しく書くことにします。ではソースをどうぞ。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml2.dtd">
<html xmlns="http://www.w3.org/2002/06/xhtml2/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2002/06/xhtml2/
http://www.w3.org/MarkUp/SCHEMA/xhtml2.xsd"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<head>
<title>Embedding Account Autodiscovery in XHTML2 Documents</title>
<link rel="foaf:maker">
<link property="foaf:holdsAccount">
<meta property="foaf:accountName" content="hatena"/>
<link property="foaf:accountServiceHomepage"
href="http://www.hatena.ne.jp/"/>
</link>
</link>
</head>
<body></body>
</html>
長く見えるのですが、head要素内の情報（title以外）がAccount AutodiscoveryのRDF版と等価です。そのはず。
現在のドラフト（2005年5月27日版）にあるMetainformation ModuleとMetainformation Attributes Moduleに沿って書いてあるので、これからの変更により変わっていくかもしれません。
とりあえず、XTHML2でのメタデータ表現はこうなるぞってのを書いてみたかったので書いてみました。ではでは。
追記追記。dc:creatorからfoaf:makerになったので、変更しました。
そのページが誰のものなのかを示す識別子を埋め込む仕様を考えていますにて、ユーザIDをHTMLに埋め込む方法を考えているらしいです。
いくつか例が挙げられているのですが、Dublin Coreの例において
<meta name="DC.creator" content="hatena:id:naoya">
こういう使い方をしてもいいものなのでしょうか
とありますが、問題ありません。HTMLやXHTMLにDublin Coreを埋め込むときの指針として、Expressing Dublin Core in HTML/XHTML meta and link elementsという文書がDublin Coreより勧告されています。naoyaさんが書いた例は、その仕様にきちんと沿ったものとなっています。
ただ、DCが何を意味するのかわからないので、link要素にて次のコードを埋め込み、「DC」というprefixがDublin Coreのものであることを示さなければなりません。
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
これでおっけー。
さて、以下は僕が考えたもの。naoyaさんはhatena:id:naoyaというスキームをmeta要素に埋め込んでいるのですが、はてなにはユーザ情報のページが備わっていますし、ただ単にそこにlink要素でリンクを張れば良いんじゃないかと思いました。hatena:id:naoyaっていうのが仕様として必要なら、titleで補うのはどうでしょう。というわけで僕の例はこちら。
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> <link rel="DC.creator" title="hatena:id:naoya" href="http://www.hatena.ne.jp/user?userid=naoya">
先ほど紹介したDublin Core in HTMLの仕様書には、link要素を用いる方法もあるので、それを単純に利用しました。
naoyaさんのところのコメントにはFOAFを使うという案があるのですが、今のHTML仕様だとそこら辺を埋め込むのが非常にむつかしい（weblogの文書とユーザIDを記述するには、間に人をはさまないといけない）ので、あまりおすすめできません。
あと、HTMLにXMLを埋め込んで気持ち悪い感じ
だけで済んでるので、はてなだと正しく使えなさそうという感じがします（チラシのなんとか）。
というわけで、意見を投げてみたり。
ページにはてなIDを埋め込むにて、head要素内にIDリンク埋め込むという手法の欠点が挙げられていました。
ただ、metaはhead内なので、やっぱりウェブログサービスだと厳しそう。
ほんとだ。確かにそういうことを考えるとmeta要素を使うのも、僕が考えたものも使えなくなってしまいます。うーん。
さてさて、エントリにはmicroformats的手法と称して、class属性を用いてaddress要素にはてなIDを記述する例がありました。
<address> <div class="mailto">mailto:altair@...</div> <div class="hatena">id:aql</div> </address>
なかなか面白そうです、ただ構造に問題があったり。address要素にはブロック要素を含むことができないので、span要素を使うことになります（address要素を使わなければOK）。というわけで、ブラウザでの表示を意識してマークアップしなおしてみます。
<address> <span class="hatena">id:aql</span> (<span class="mailto">mailto:altair@...</span>) </address>
こんな感じかしら。
さて、これを見てhCardを思い出しました。vCardの情報をHTMLで表現するためのmicroformatなんですが、ここら辺と組み合わせ、足りないものは定義してみると面白いかも。というわけで、tipjarというmicroformatを考えてみます。
<address class="tipjar">
<a class="userID" rel="tipjarURL"
href="http://www.hatena.ne.jp/user?userid=kotastyle">hatena:id:kotastyle</a>
</address>
tipjarというclass属性をもつコンテナを用意し、rel属性にtipjarURLという投げ銭に関するリンク（またはユーザ情報のページ）、class属性にはuserIDという二つの値により、URLとIDを結びつけます。
そうそう、address要素にこだわらなくても、たとえば管理者のプロフィールが書いてあるdiv要素なんかに組みこめば問題ありません。はてなダイアリーにはprofileモジュールがあるので、それに組みこんでしまうとか。
tipjarフォーマットができたので、hCardと組み合わせてみます。
<address class="vcard tipjar">
<a class="url n" href="http://webweaver.g.hatena.ne.jp/kotastyle/">kota</a>
(<a class="userID" rel=&quo;tipjarURL"
href="http://www.hatena.ne.jp/user?userid=kotastyle">hatena:id:kotastyle</a>)
</address>
こんな感じだと、microformatとして成立可能で、はてな外にもオープンにできるんじゃないかしら。
追記追記。rel属性の存在をすっかり忘れていました。tipjarURLはrel属性の値として書き換えてみました。
class属性値の併記はちょっと意味をぼかしてしまうので、rel属性をうまく使える場合はこちらの方が望ましいかと。
aql確かに、中にblock書けませんでした。うっかり。
ren-bookmarkはじめまして。
素直に、
<address class="vcard">
<a class="url n" href="http://webweaver.g.hatena.ne.jp/kotastyle/">kota</a>
(<a class="userID" rel="tipjar" href="http://www.hatena.ne.jp/user?userid=kotastyle">hatena:id:kotastyle</a>)
</address>
でいいような気がしました(rel-tipjar語彙を作成して組み合わせるイメージ)が如何でしょうか？
はてなの RSS (RDF/XML) には，いつもがっかりにて、はてなマップのRSSが持つ問題についてまとめられています。同じ事を書こうと思ってたのですが遅くなってしまったので、位置情報についての補足なんかを。
はてなマップのRSSには、各itemにgeo:latとgeo:longで位置情報が記述されているのですが、現在の記述ではRDFを解釈すると不都合が起こる場合があります。「株式会社はてな」のキーワードを例に取ってみます。
<item rdf:about="http://d.hatena.ne.jp/keyword/%b3%f4%bc%b0%b2%f1%bc%d2%a4%cf%a4%c6%a4%ca"> <title>株式会社はてな</title> <link>http://d.hatena.ne.jp/keyword/%b3%f4%bc%b0%b2%f1%bc%d2%a4%cf%a4%c6%a4%ca</link> <description>人力検索サイトはてなの開発・運用やWEBおよび携帯コンテンツの企画立案、開発をやってます。 2004年2月1日をもって有限会社から株式会社に組織変更をおこない「 ...</description> <geo:lat>35.6512</geo:lat> <geo:long>139.6980</geo:long> </item>
RDFの解釈ではキーワード「株式会社はてな」のURLが主語となり、title, link, description, geo:lat, geo:longは「キーワードのURLが指すもの」のプロパティとなります。「キーワードのURLが指すもの」は一般には「リソース」となるのですが、いくつかのボキャブラリによりRDFが構成されている場合、各ボキャブラリのスキーマによりリソースの存在範囲が制限される場合があります。
さて、「株式会社はてな」というキーワードURLは、geo:latおよびgeo:longという二つのプロパティを持っています。Geo Vocabularyのスキーマでは、「geo:latおよびgeo:longをプロパティに持つリソースは、geo:SpatialThingというクラスのインスタンスになる。」と定義されているのです。
geo:SpatialThingの定義にはAnything with spatial extent
とあり、これは位置や大きさを持つ（空間に存在する）ものを意味します。つまりキーワードのURLが指すリソースは、空間的に存在するものに限定されちゃうんですよ。
はい、ここで問題がでてきます。キーワード「株式会社はてな」のURLが表すリソースは、キーワードについて解説した「Web上の文書」であり、空間的に存在しないものなんです。つまり、空間的に存在しないものが、緯度経度をもつという矛盾が生じるのです。
はてなフォトライフの写真がはてなマップ上にある場合も同様で、デジタル画像が緯度経度を持つことになります。言葉を読むとそうおかしくないのですが、デジタル画像は「撮影した地点の緯度および経度の情報」を持っているのであり、画像そのものに緯度経度があるわけではありません。なので、こちらもおかしなことになります。
というわけで、問題とならないようなフィードを考えてみます。
<item rdf:about="http://d.hatena.ne.jp/keyword/%b3%f4%bc%b0%b2%f1%bc%d2%a4%cf%a4%c6%a4%ca"> <title>株式会社はてな</title> <link>http://d.hatena.ne.jp/keyword/%b3%f4%bc%b0%b2%f1%bc%d2%a4%cf%a4%c6%a4%ca</link> <description>人力検索サイトはてなの開発・運用やWEBおよび携帯コンテンツの企画立案、開発をやってます。 2004年2月1日をもって有限会社から株式会社に組織変更をおこない「 ...</description> <foaf:topic parseType="Resource"> <geo:lat>35.6512</geo:lat> <geo:long>139.6980</geo:long> </foaf:topic;> </item>
foaf:topicにparseType="Resource"をつけて、geo:latとgeo:longを囲ってやります。ほかにもいろいろな書き方がありますが、多分この変更が一番楽で、マークアップの変更による影響が少ないものかと思われます。
<dcterms:spatial parseType="Resource"> <!-- 又は<dc:coverage parseType="Resource"> --> <geo:lat>35.6512</geo:lat> <geo:long>139.6980</geo:long> </dcterms:spatial;>
「FOAFって人についてでしょ？」みたいなステレオタイプを持っていて、なんとなくfoaf:topicを使いたくない場合は、まあdcterms:spatial又はそのスーパープロパティなdc:coverageあたりがいいかなと。
さてさて、このRSSを見て思い出したのは位置情報を含めたGeoURLのRSSフィードです。もしかして、これを参考にしたのかな。
GeoURLは緯度と経度情報を埋め込んだWebサイトのデータベースなのですが、出力されるRSSフィードは現在のはてなマップフィードによく似た構造となってます。
<item rdf:about="http://ericrichardson.com/"> <title>eWorld: eric richardson meets the web</title> <link>http://ericrichardson.com/</link> <description>About 9.4 km away. Near Los Angeles.</description> <geourl:longitude>-118.25201</geourl:longitude> <geourl:latitude>34.0456</geourl:latitude> </item>
geourl:longitudeおよび、geourl:latitudeという独自のプロパティを用いて、緯度と経度情報を記述してあります。どのような定義をしてあるかがわからないので果たしてこれは良いのか悪いのかわかりませんが、「リソースに関連した緯度および経度」というものをそれぞれ表していると考えて納得できます（バッドノウハウ）。
はてなもフォトライフのRSSでhatena:imageurlとか独自の語彙を定義してあるくらいなんで、位置情報に関しても同じ事をすればよかったのに。やってることにconsistencyをあんまり持たないのが悪くもはてなだなあと思ったり思わなかったり。
まあそんなことはさておいて、ぼちぼち RSS 2.0 に移行時かな
とか破壊的なことは言わないで（「移行」とか言うのは「がっかり」しちゃいます）、ちょこっと追加はいかがかしら。
追記。はてなマップのRSSとはてなマップのRSS配信開始についてにトラックバックを送ったんですが、届いてないようなのでリンク張ってみますよ。言及リンクないとできなくなったとかかしら。
さらに追記。うまく送ることができました、IEで。なんでだー
ネタだったんですか？
「バージョン番号同じだけどどうするんだろう…」
と思いっきり釣られてしまった…