セマンティック・マイクロブログ

ソーシャルメディアとマイクロブログ
マイクロブログのデータモデル
APIもしくはフィード集約によるコンテンツ連繋
Twitterのデータ
Timelogのデータ
FriendFeedのデータ
共有可能なデータ記述
SIOC：社会コンテンツ記述のRDF語彙
SIOCを用いたマイクロブログのデータ表現
FOAF：人とその関係を記述するRDF語彙
FOAFによるマイクロブログ作者の表現
SIOCとFOAFによるマイクロブログの連動
SIOCと社会グラフ
セマンティック・マイクロブログの実践
マイクロブログ・コンテンツの検索と活用
位置情報の導入
GPSとGeoメタデータ
Geocoding
Geohash
位置記述の精細度とプライバシー
位置情報を加えたデータモデル
Geohashと検索
まとめ
参照先

クリック/タップや→/Nキーで次のページに進みます。Aキーで一括表示と切り替え可。

1 ソーシャルメディアとマイクロブログ

SNSとソーシャルメディア
- SNS：個人のプロフィールや関心事などを（範囲を限定して）公開し社会的ネットワークを構成
- ソーシャルメディア：社会ネットワークとコンテンツ・メッセージ共有の組み合わせ
- Ambient Intimacy（何気なくそこにあるような親しみ）の感覚
- データの互換性、共有が課題
マイクロブログ（Microblogging）
- 限られた字数の最小限の＝気軽に書けるコンテンツ
- ゆるやかで手軽なコミュニケーション
  - Why We Twitterの考察では、日常会話＋情報探索/共有
- フットワークの軽さとモバイルとの相性
  - 携帯端末からも簡単に読み書きできる → 発信する位置という新たなメタデータ

2 マイクロブログのデータモデル

コンテンツのモデル
- ポストの内容（本文）
- ポストのメタデータ（タグ、返信など）
  - サービスによってさまざまな形態
  - ポスト本文中に「マイクロフォーマット」的に埋め込むことがある
  - @によるメッセージ（返信）、#によるハッシュタグ、L:による位置情報など
- ポストの作者
  - コンテンツの作者は通常「人間」（たまにロボット）だが、サービス上では「ユーザアカウント」に結び付けられる
作者と社会ネットワークのモデル
- 作者のプロフィール
  - ニックネーム、本名、ホームページなど、本人の識別情報
  - 関心事項、他に利用しているサービスのアカウントなど、周辺情報
- フォローや返信によるネットワーク構造
  - フォロー：作者（ユーザアカウント）の間のネットワーク
  - 返信：コンテンツの間のネットワーク

3 APIもしくはフィード集約によるコンテンツ連繋

RSS/Atomフィードによるコンテンツ収集
- （マイクロ）ブログは基本的にフィードを出力している
- フィードのコンテンツ記述モデルはおおむね共通なので、集約しやすい
- 一方で、フィードは社会ネットワーク情報は基本的に含まない
  - しかも、マイクロブログのRSS/Atomは、作者情報を省略している…
APIによるサービス独自データの取得
- 各サービスのコンテンツおよびリンク情報をほぼ取得できる
- 一方、サービスごとにデータ形式はばらばら
集めたデータを共通モデルに置き換えて提供
- 細かなモデルの違いの吸収、日付形式などの統一により、検索や再利用が容易になる
- 例：FriendFeedでコンテンツを集め、フィードやAPI経由でアクセス
- 複数のサービスに対応する“Twitterクライアント”で集めたコンテンツを一覧

4 Twitterのデータ

Twitter独自XML

<status>
  <id>823422648</id>
  <text>@gridinoc, same API URI (and same code) sometimes works...</text>
  <created_at>Fri May 30 15:39:55 +0000 2008</created_at>
  <source>web</source>
  <truncated>false</truncated>
  <favorited>false</favorited>
  <in_reply_to_status_id>823401484</in_reply_to_status_id>
  <in_reply_to_user_id>5017391</in_reply_to_user_id>
  <user>
    <id>4099141</id>
    <name>Masahide KANZAKI</name>
    <screen_name>_masaka</screen_name>
    <location>Tokyo, Japan</location>
    <description>A pure tone enthusiast, and a man of ...</description>
    <profile_image_url>http://...<profile_image_url>
    <url>http://www.kanzaki.com/</url>
    ...
  </user>
</status>

各「ステータス」は独自の<id>で識別（グローバルには識別できない）。内容が<text>、作者（もしくはそのアカウント）が<user>で表現される
返信の場合、<in_reply_to_status_id>と<in_reply_to_user_id>でメッセージがつながる
<user>内で簡単なプロフィールが表現される

Atomによるフィード

<entry>
  <id>tag:twitter.com,2008-05-30...</id>
  <title>_masaka: @gridinoc, same API URI (and same code) sometimes works...</title>
  <content type="html">_masaka: @gridinoc, same API URI (and same code) sometimes works...</content>
  <link rel="alternate"
       href="http://twitter.com/_masaka/statuses/823422648" type="text/html"/>
  <published>2008-05-30T15:39:55+00:00</published>
  <updated>2008-05-30T15:39:55+00:00</updated>
</entry>

内容がtitleとcontentの両方に。userやコンテンツリンク（返信）の情報は失われる。

5 Timelogのデータ

Timelog独自XML

<entry>
  <id>27508738ea26b9b8213db737d3be8289700ef63b427092</id>
  <memo>フリードリヒ・エルンスト・フェスカ（Fesca）の交響曲第2番を...</memo>
  <link rel="alternate" type="text/html"
     href="http://timelog.jp/msg/?27508738ea26b9b8213db737d3be8289700ef63b427092"/>
  <modified>2008/06/03 22:54:56</modified>
  <tag>music</tag>
  <toid>...</toid>
  <toname>...</toname>
  <replyid>...</replyid>
  <tododate></tododate>
  <author>
    <id>masaka</id>
    <name>masaka</name>
    <image>
      <normal>http://img.timelog.jp/imageuserface/masaka.jpg</normal>
      <thumb>http://img.timelog.jp/imageuserface/masaka_m.jpg</thumb>
      <small>http://img.timelog.jp/imageuserface/masaka_s.jpg</small>
    </image>
  </author>
</entry>

各「ポスト」は、独自の<id>をもち、内容は<memo>、作者は<author>で表現される
<toid>、<replyid>などでSNS的なつながりが表現されるが、作者のプロフィール情報は名前、アイコンのみ。タグは<tag>で示される。

Atomによるフィード

<entry>
 <id>27508738ea26b9b8213db737d3be8289700ef63b427092</id>
 <title>フリードリヒ・エルンスト・フェスカ（Fesca）の交響曲第2番を...</title>
 <link rel="alternate" type="text/html"
     href="http://timelog.jp/msg/?27508738ea26b9b8213db737d3be8289700ef63b427092"/>
 <issued>2008-06-03T22:54:56+09:00</issued>
 <modified>2008-06-03T22:54:56+09:00</modified>
 <author>
  <name>masaka</name>
 </author>
</entry>

内容はtitleのみ（contentとの重複はない）、作者名はauthor内に保持されている。
- ※2008年6月現在で、古いドラフト（Atom 0.3）のXML名前空間http://purl.org/atom/ns#が用いられている

6 FriendFeedのデータ

Atomを利用したデータ表現

<entry>
  <title type="text">@gridinoc, same API URI (and same code) sometimes works...</title>
  <updated>2008-05-30T15:39:55Z</updated>
  <published>2008-05-30T15:39:55Z</published>
  <id>tag:friendfeed.com,2007:266de66a-b653-b8da-d1d2-c96a1cee19dd</id>
  <link href="http://twitter.com/_masaka/statuses/823422648"
        rel="alternate" type="text/html"/>
  <ff:id>266de66a-b653-b8da-d1d2-c96a1cee19dd</ff:id>
  <ff:user>
    <ff:id>38448916-2977-11dd-bca5-003048343a40</ff:id>
    <ff:name>Masahide Kanzaki</ff:name>
    <ff:nickname>mkanzaki</ff:nickname>
    <ff:profileUrl>http://friendfeed.com/mkanzaki</ff:profileUrl>
  </ff:user>
  <ff:service>
    <ff:id>twitter</ff:id>
    <ff:name>Twitter</ff:name>
    <ff:iconUrl>http://...</ff:iconUrl>
    <ff:profileUrl>http://twitter.com/_masaka</ff:profileUrl>
  </ff:service>
</entry>

FriendFeedのデータは、XMLもAtomも同等
idによる識別はできるが、オリジナルとは異なる、FriendFeedとしてのIDになっている
内容はtitleで、作者はFriendFeed独自のff:userとff:serviceで示される。
返信関係、タグなどのサービス独自情報は保持されない

7 共有可能なデータ記述

Atomによるデータ記述
- コンテンツに関する記述には十分で、互換性も高い
  - titleが必須なのは、マイクロブログにはやや不向きか
- タグ、返信などの付加情報も、別の名前空間の語彙を追加して記述可能
- 作者情報もひととおり記述できるが、作者間の関係などになると、Atomの枠を超える
シンプルな共通の枠組みRDFを使う
- Resouce Description Framework（RDF)：ウェブ上のリソースを記述するための共通枠組み
- 様々にリンクする関係（グラフ）をトリプル（文）単位で記述
  - グラフのノード（起点、終点）が主語、目的語、リンクがプロパティ（述語）
- ノード、リンクをURIで名前付けして、グローバルに共有
  - 異なる業界やサービスで作られたデータも、確実に識別、併合できる：LinkingOpenData
- 複雑なグラフも単純なトリプルに分解できるので、多様な関係を柔軟に記述できる
  - サービスごとに情報が異なっても、コンテンツと作者でモデルが異なっても、集約が容易

8 SIOC：社会コンテンツ記述のRDF語彙

SIOCとは
- フォーラム、Wiki、ウェブログなどのオンラインコミュニティのコンテンツを記述
- 仕様はSemantically-Interlinked Online Communities (SIOC)を参照
SIOC Coreの主な語彙
- 各人のウェブログ全体などを表すContainer
- ポストの単位を表すItemとそのサブクラスPost
- 投稿の内容を表すcontent、内容の対象（書評、ブックマークなど）を表すabout
- 投稿者の“ユーザアカウント”を表すhas_creator
- （図はSIOC仕様書より）

9 SIOCを用いたマイクロブログのデータ表現

SIOC Coreで基本内容は記述できる
- ```
<sioc:Post rdf:about="http://twitter.com/_masaka/statuses/823422648">
 <sioc:content>@gridinoc, same API URI (and same code) sometimes works...</sioc:content>
 <dc:created>2008-05-30T15:39:55Z</dc:created>
 <sioc:reply_of rdf:resource="http://twitter.com/gridinoc/statuses/823401484/"/>
 <sioc:has_creator>
  <sioc:User>
   <foaf:isPrimaryTopicOf rdf:resource="http://twitter.com/_masaka"/>
  </sioc:User>
 </sioc:has_creator>
</sioc:Post>
```
  - 「ポスト」をURIで識別し、サービスを超えた共有を可能に（独自idとの違い）
  - 作成日にはDublin Coreを、返信を示すにはSIOCのreply_ofを利用
  - 「作者」（人物）ではなく、ポスト主である「ユーザアカウント」をsioc:has_creatorで記述
  - ユーザアカウントの持ち主の「アカウントページ」をfoaf:isPrimaryTopicOfで識別
- $図7:{Twitter-post}--sioc:content-->"...";--sioc:reply_of-->{another-post};--sioc:has_creator-->{masaka-account}--foaf:isPrimaryTopicOf-->{account-page}$

10 FOAF：人とその関係を記述するRDF語彙

FOAFとは
- 人とそのつながりを記述する共通語彙
- Friend of a Friend (FOAF) projectやメタデータによる知人ネットワークの表現を参照
- 例えばGoogle Social Graph APIでFOAFデータを取り込み、社会グラフを作ることができる
FOAFの主な語彙
- プロフィールを表現：name, nick, homepage, weblog, interestなど
- 知人関係を示す：knows
- ウェブ上のコンテンツやサービスを示す：OnlineAccount, holdsAccount, isPrimaryTopicOf

11 FOAFによるマイクロブログ作者の表現

holdsAccountでユーザ・アカウントを示す

<foaf:Person rdf:about="urn:pin:MK705">
  <foaf:name>Masahide Kanzaki</foaf:name>
  <foaf:homepage rdf:resource="http://www.kanzaki.com/"/>
  <foaf:holdsAccount>
    <foaf:OnlineAccount>
      <foaf:isPrimaryTopicOf rdf:resource="http://twitter.com/_masaka"/>
    </foaf:OnlineAccount>
  </foaf:holdsAccount>
  <foaf:holdsAccount>
    <foaf:OnlineAccount>
      <foaf:isPrimaryTopicOf rdf:resource=" http://masaka.timelog.jp/ "/>
    </foaf:OnlineAccount>
  </foaf:holdsAccount>
  ...
</foaf:Person>

12 SIOCとFOAFによるマイクロブログの連動

同じ作者が異なるサービスに投稿したコンテンツを結びつける
- foaf:isPrimaryTopicOfはIFP（IDとして機能するプロパティ）なので、同じ値を持つ主語が併合される
- TwitterとTimelogのポストが同じ「人物」によるものであることが分かる

13 SIOCと社会グラフ

返信などの関係を辿ることで、作者間の社会グラフを得る
- sioc:reply_ofを辿ることで、異なる作者のマイクロブログコンテンツを結びつける
- reply_ofを辿ったコンテンツのsioc:has_creator、foaf:isPrimaryTopicOfをつないでいくと、元コンテンツ作者と、返信先コンテンツ作者のつながりが得られる
- $図10:{作者A}--foaf:holdsAccount-->{Account A}<--sioc:has_creator--{Post A}--sioc:reply_of-->{Post B}--sioc:has_creator-->{Account B}<--foaf:holdsAccount--{作者B}$

14 セマンティック・マイクロブログの実践

共有可能なモデルでコンテンツを生成し、既存サービスに送る
- マイクロブログコンテンツをユーザが手元で生成（RDFに基づくモデル） → 必要に応じて適当な既存サービスにアップロードする
- 例：SMOB - Semantic MicroBlogging
- “Twitterクライアント”でコンテンツを生成し、それぞれのサービスに送信、オリジナルは手元に
既存サービスのデータを収集し、共通モデルに変換
- APIなどでデータを収集 → 共通モデルに変換して利用
- 例：Planet masakaでの収集実験
- “Twitterクライアント”などで取り込んだログを、RDFモデルに変換して保存
- コンテンツだけでなくそれらのリンク情報も得られる
作者（ユーザ）が自在に活用できるデータ
- いずれの手段の場合も、データは（サービスのものではなく）作者のもの
- データをRDFにすることで、再利用や異なる種類のデータとの連動が容易に

15 マイクロブログ・コンテンツの検索と活用

SPARQLによる検索

RDFで記述しておけば、SPARQLを用いてさまざまな検索が可能
例：ホームページが<http://www.kanzaki.com/>である作者のポストを全て取り出す：

PREFIX sioc: <http://rdfs.org/sioc/ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?id ?memo WHERE {
  ?id sioc:content ?memo;
      sioc:has_creator [foaf:isPrimaryTopicOf ?account].
  ?person foaf:homepage <http://www.kanzaki.com/>;
      foaf:holdsAccount [foaf:isPrimaryTopicOf ?account].}

ユーザの社会グラフを取り出す

例：sioc:reply_ofをたどって、作者同士のつながりのグラフを得る：

PREFIX sioc: <http://rdfs.org/sioc/ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX sn: <http://purl.org/net/ns/socialnet#>
CONSTRUCT {
  ?prof1 sn:owner_contacts ?prof2.
} WHERE {
  ?item1 sioc:reply_of  ?item2 ; 
         sioc:has_creator [foaf:isPrimaryTopicOf ?prof1].
   ?item2  sioc:has_creator [foaf:isPrimaryTopicOf ?prof2].}

SPARQLのCONSTRUCTによって新しいグラフを作り出している

16 位置情報の導入

コンテンツ（の対象）の位置
- Flickrの写真に付与したGPSデータ
- ウェブログなどで話題にしたイベントの開催場所
コンテンツ作者の位置
- プロフィールに記載された地域情報
- モバイル端末から送信するときの、出先の位置
  - 端末とGPSの連動
  - L:マイクロフォーマット（追記：ナノフォーマットと呼ぶそうだ）による地域表記
- 場所に「チェックイン」するというBrightkiteのアプローチ
位置情報の利用
- コンテンツを地図上に表示する：Flickr map、twittervisionなど
- ある地域に関連する情報の検索：geocachingなど

17 GPSとGeoメタデータ

位置データを記述するRDF語彙

W3C 基本Geo語彙を用いて緯度、経度を記述する

<item rdf:about="...">
  <foaf:topic>
    <rdf:Description>
     <rdfs:label>ビジョンセンター</rdfs:label>
     <geo:lat>35.6972</geo:lat>
     <geo:long>139.7682</geo:long>
    </rdf:Description>
  </foaf:topic>
  ...
</item>

GPSデータの留意点
- 高精細度：正確な位置を表現できる vs 対象によってはプライバシーが守られない
- 場所の「識別子」には使いにくい
  - 同じ場所で計測しても、微妙に違う値になる＝誤差の範囲でも、IDとしては異なる
- 写真に付与されるGPS位置は、撮影場所であって撮影対象の位置ではない
  - 写真のメタデータとして直接記述すると、おかしなことになる
  - DPDのような語彙を使って間接的に記述する（後述#21）

18 Geocoding

住所、地名から位置情報を得られるサービス
- 地図サービスの検索引数に住所を与えるだけで適切な地域の地図が示される
  - http://maps.google.com/maps?q=東京都千代田区神田淡路町2-10-6
- 住所、地名から緯度経度データを取得できるサービス
  - GeoNamesサービス、Googlemaps APIのgetLatLng()
- L:マイクロフォーマットから地名を取り出して、簡単に地図にプロットできる
位置情報の精細度を制御しやすい
- 正確な位置を知らせたくなければ、市町村や都道府県レベルなど、精細度（粒度）を調整できる
- 精細度に応じて地図表示のスケールを変更
  - http://maps.google.com/maps?q=東京都千代田区とhttp://maps.google.com/maps?q=東京都では異なるスケールで表示される
- 緯度経度を逆に地名に変換する方が好都合な場合もある
  - 例：MovaTwitterの「イマココ」サービスなど

19 Geohash

緯度＋経度を“1つの”名前で識別
- 緯度、経度という2つのデータではなく、ひとつの名前（値）として位置情報を示す
- Geohash.orgのサービスのために考案されたGeohashは、緯度、経度を一組の英数字で表現→文字列には緯度経度に対応した順序がある
- ハッシュ文字列の後ろを削っていくと、同じ位置の粒度の低い緯度経度が得られる＝住所表記と同様の精細度コントロールができる
- 緯度経度 Geohash
  
  35.6972 139.7682 xn77hd2p7
  
  35.70 139.77 xn77hd2
  
  35.7 139.8 xn77h
Geohashを「場所」のURIとして使う
- http://geohash.org/xn77hd2p7はサービスのURIで、“場所”を直接識別するわけではない
- 試験的なGeohash URIとしてhttp://www.kanzaki.com/ns/geo/xn77hd2p7のかたちを検討中
  - このURIは「場所」＝ネットワーク上には無いもの＝を表す識別子
  - ブラウザで辿ると、RDF/XML表現の「ページ」URIにリダイレクトされる設定
  - 日付や名称を加えてイベントを表すURIにするアイデアも

緯度	経度	Geohash
35.6972	139.7682	xn77hd2p7
35.70	139.77	xn77hd2
35.7	139.8	xn77h

20 位置記述の精細度とプライバシー

位置データに粒度を反映させる
- 緯度、経度の小数点以下桁数で粒度を表現する
  - 139.7682と139.8を、前者なら10m単位程度、後者なら10km単位程度の精細度として使い分けるなど
  - 参考：位置データと精細度
- 緯度、経度に加えて粒度（精細度）情報をセットにした位置情報を考える
- 例：Flickr APIで写真の位置情報とともに返されるaccuracy、Digital Picture/Document Description vocabularyのdpd:granularity
- ```
<dpd:Place>
  <geo:lat>35.6972</geo:lat>
  <geo:long>139.7682</geo:long>
  <dpd:granularity>2</dpd:granularity>
  
</dpd:Place>
```

対象の位置を間接的に示す

場所を直接示すのではなく、ある緯度経度の「近く」にあることで間接的に示す。たとえばfoaf:based_near

<foaf:Person rdf:about="urn:pin:MK705">
  <foaf:name>Masahide Kanzaki</foaf:name>
  <foaf:based_near>
    <dpd:Place>
      <geo:lat>35.7</geo:lat>
      <geo:long>139.7</geo:long>
    </dpd:Place>
  </foaf:based_near>
  ...
</foaf:Person>

21 位置情報を加えたデータモデル

L:マイクロフォーマットを使ったポストをRDFで表現する

「_masaka: いまイベントの真っ最中。L:東京都千代田区神田淡路町」
ポストが「生成された」場所を示すために、dpd:generatedプロパティを用いる

<sioc:Post rdf:about="http://twitter.com/_masaka/statuses/...">
 <sioc:content>いまイベントの真っ最中。L:東京都千代田区神田淡路町</sioc:content>
 <dc:created>2008-06-15T01:30:00Z</dc:created>
 <sioc:has_creator>
  <sioc:User>
   <foaf:isPrimaryTopicOf rdf:resource="http://twitter.com/_masaka"/>
  </sioc:User>
 </sioc:has_creator>
 <dpd:generated>
  <rdf:Description>
   <geo:lat>35.6972</geo:lat>
   <geo:long>139.7682</geo:long>
  </rdf:Description>
 </dpd:generated>
</sioc:Post>

22 Geohashと検索

位置情報をGeohashを用いて記述しておく

<sioc:Post rdf:about="http://twitter.com/_masaka/statuses/...">
 <sioc:content>いまイベントの真っ最中。L:東京都千代田区神田淡路町</sioc:content>
 ...
 <dpd:generated rdf:resource="http://www.kanzaki.com/ns/geo/xn77hd2p7"/>
</sioc:Post>

位置情報をコンパクトに記述できることに加えて…

Geohashを利用した検索
- ハッシュの先頭文字が同じなら、同じエリアに含まれることを利用した検索が可能
- Geohashでは、秋葉原ダイビル：xn77hdg4b、ビジョンセンター：xn77hd2p7
- 「Geohashの先頭がxn77hd」という粗い粒度の条件で検索すると、両方がマッチする
  - 実用には、単なる文字列前方一致ではなく、“xn76ur6より大きくxn77hfbより小さいハッシュ”などの比較条件が必要

23 まとめ

マイクロブログのデータを共有・再利用する
- RDFの枠組みと共通の語彙を用いてデータを記述する
- SIOC語彙を利用してコンテンツを記述し、異なるサービス・領域のデータも共通に扱えるようにする
- ユーザ・アカウントをSIOCとFOAFで表現し、社会グラフを得る
- RDF関連ツールを利用して検索したり再利用する
モバイルと相性の良いマイクロブログで位置データを活用する
- GPSを用いたり、Geocodingで地名から位置情報を取り出す
- プライバシーなどの観点から、位置情報の粒度に配慮する
- 位置情報を与える対象を明確にして、RDFで記述する

24 参照先

参照したリソース
1. Ambient Intimacy, by Leisa Reichelt, 2007-03-01
  <http://www.disambiguity.com/ambient-intimacy/> (☞#1)
2. Why We Twitter: Understanding Microblogging Usage and Communities, by Akshay Java et al., 2007-08
  <http://ebiquity.umbc.edu/blogger/2007/08/02/why-we-twitter/> (☞#1)
3. RDF - リソース表現のフレームワーク
  <http://www.kanzaki.com/docs/sw/rdf-model.html> (☞#7)
4. Linking Open Data, W3C SWEO Community Project
  <http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData> (☞#7)
5. SIOC Core Ontology Specification, by Uldis Bojars et al., 2005-04-07
  <http://rdfs.org/sioc/spec/> (☞#8)
6. Dublin Core: メタデータを記述するボキャブラリ
  <http://www.kanzaki.com/docs/sw/dublin-core.html> (☞#9)
7. メタデータによる知人ネットワークの表現
  <http://www.kanzaki.com/docs/sw/foaf.html> (☞#10)
8. Google Social Graph API
  <http://code.google.com/apis/socialgraph/> (☞#10)
9. SMOB - Semantic MicroBlogging
  <http://smob.sioc-project.org/> (☞#14)
10. マイクロブログ収集の実験：Planet masaka
  <http://www.kanzaki.com/info/planet> (☞#14)
11. SPARQL Query Language for RDF
  <http://www.w3.org/TR/rdf-sparql-query/> (☞#15)
12. Brightkite - the location-based social network
  <http://brightkite.com/> (☞#16)
13. Flickr map
  <http://www.flickr.com/photos/masaka/map/> (☞#16)
14. twittervision
  <http://twittervision.com/> (☞#16)
15. geocaching
  <http://geocaching.com/> (☞#16)
16. Basic Geo (WGS84 lat/long) Vocabulary, by W3C Semantic Web Interest Group, 2003-01
  <http://www.w3.org/2003/01/geo/> (☞#17)
17. GeoNamesサービス
  <http://www.geonames.org/> (☞#18)
18. Googlemaps API
  <http://code.google.com/apis/maps/documentation/reference.html> (☞#18)
19. MovaTwitter
  <http://movatwitter.jp/> (☞#18)
20. Geohash.org
  <http://geohash.org/> (☞#19)
21. 位置データと精細度
  <http://www.kanzaki.com/docs/sw/geoinfo.html#geo-precision> (☞#20)
22. Digital Picture/Document Description vocabulary
  <http://www.kanzaki.com/ns/dpd> (☞#20)