weavin'

2005-08-190106

[][][] Multiple Accounts in Autodiscovery

昨日書こうと思っててすっかり忘れてたことを。はてなだけではなく、別のアカウント情報を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を記述するのをおすすめしたいです。

はてな側にもこれをどこかに書いておいて欲しいなとおもったり。

2005-08-180105

[] Yet "Another" RSS 3.0

RSS 3.0ですって。もうAtomも完成したんで特に騒ぐ気もないんですが、ちょっと面白かったので。

実は3年前の「フィード戦争」の時に、Dave Winerをちゃかそうとテキスト版のRSS 3.0が作られたりしたんですよね。まあネタなんで、RSSのグループに入れてもらってるのを見たことがないんですが。

そういえばRSS 1.0はRDF/XMLを構文として採用してますが、その気になればN3とかTurtleでプレーンテキストのフィードとか作れちゃうんですよね。contentモジュールとかは扱えませんが。

そろそろAtomでみんな妥協しないかい。

TELLTELL2005/08/19 23:22初めまして。
ネタだったんですか?
「バージョン番号同じだけどどうするんだろう…」
と思いっきり釣られてしまった…

2005-07-180103

[] Embedding UserID in HTML

そのページが誰のものなのかを示す識別子を埋め込む仕様を考えていますにて、ユーザ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を埋め込んで気持ち悪い感じだけで済んでるので、はてなだと正しく使えなさそうという感じがします(チラシのなんとか)。

というわけで、意見を投げてみたり。

[][] More on "NagesenID" in HTML

ページにはてな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属性をうまく使える場合はこちらの方が望ましいかと。

aqlaql2005/07/19 13:12確かに、中にblock書けませんでした。うっかり。

ren-bookmarkren-bookmark2007/12/17 09:36はじめまして。
素直に、

<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語彙を作成して組み合わせるイメージ)が如何でしょうか?

2005-07-160102

[][] Geographical Information in Hatena Map & GeoURL Feeds

はてなの 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で。なんでだー

2005-07-150101

[] Atom 1.0 (RC)

It’s cooked and ready to serve.というわけで、Atomフォーマットが完成したようです。Tim Brayによれば最終ドラフト(Atom 1.0)が提出され、まもなく受理されるであろうとのこと。

It will eventually get an RFC number, but that may take a while, first because the RFC Editor machinery works slowly, and secondly because we have a normative reference to Ned Freed’s re-work of the MIME-type RFCs, which isn’t quite finished yet.

ただRFCを書いたりMIMEの関係で、RFCが発行されるのはまだちょっとかかるそう。

そうそう、ひとつ前のドラフトまではNamespaceに関して次のような記述がありました。

The namespace here is a temporary one and will be changed when the IESG approves this document as a standard. At that time, the namespace will be drawn from W3C URI space. The choice of that namespace will be coordinated between the IETF and W3C through their respective liaisons.

そんな大人の事情(?)により、AtomのNamespaceはhttp://www.w3.org/2005/Atomとなります。

さてさて、フォーマットの基本部分は完成しているので、開発者の方々はフィードに関してはそろそろ移行の準備を始めてもいいんじゃないかなと。プロトコルと足並みがそろわないのがちょっと面倒そうな気もしますが。

なお、RSS 2.0とAtom 1.0を比較した文書も公開されています(work-in-progressらしい)。

楽しみだなぁ。

© 2004 kota.