DBpedia is a community effort to extract structured information from Wikipedia and to make this information available on the Web. DBpedia allows you to ask sophisticated queries against Wikipedia, and to link other data sets on the Web to Wikipedia data.
DBpedia は、みんなでがんばって、Wikipedia から構造化された情報を引き出して、それをウェブ上で使えるようにする、です。 DBpedia があれば Wikipedia に対して、洗練された問い合わせを投げられるようになります。Wikipedia のデータに、外部のデータ集合をリンクすることも。
ってことで、 DBpedia は SPARQL API を公開してくれている。
http://wiki.dbpedia.org/OnlineAccess
ここで紹介されている OpenLink の
iSPARQLを使うと、SPARQL を直感的に扱える。
新しい世界が見えるかもしれない。
1. SPARQL で問い合わせ。
Advanced タブにあるフォームから
という、 SPARQL を 実行してみる。
(http://wiki.dbpedia.org/Datasets の 4.3.2. Querying the Infobox Ontology にあったサンプルです。 )
2. 結果をみる。
なにやら結果リストが表示されたのでみる。
(↑クリックで拡大しないとわからないが) Adobe の製品などが並んでいる。
3. SPARQL のグラフを視覚的にみる。
問い合わせを実行した後に、QBE タブに行くと、問い合わせの叙述が視覚化されている。
Advanced のフォームに SPARQL を書いて、実行しないまま Visualize ボタンを押しても視覚化できる。
逆に、 QBE タブで、視覚的に SPARQL を組み立てて、 Generate ボタンを押すと、Advanced のフォームでの編集モードになる。
問い合わせの叙述が、2 つのトリプルから構成させているのが、よくわかる。
# トリプルというのは { (Subject) −(Predicate)→ (Object) } のこと。
4. 結果リソースの関連情報をたどってみる。
結果リストから AdobeFlash を選択し、Get Data Items をクリックすると、
なにやら別の結果が表示された。
5. SPARQL を確認する。
↑こういうグラフで問い合わせが行われている。
つまり、
(Subject="AdobeFlash") −(Predicate=?)→ (Object=?)
和集合
(Subject=?) −(Predicate=?)→ (Object="AdobeFlash")
↓SPARQL で書くとこう。
なるほど。
Metaweb が Freebase 用に開発した MQL のほうでも、MQL Query Editorが公開されているが、
こうやってトリプルのグラフを視覚化して見せられると、SPARQL のほうが RDF / セマンティック 風味が強い気がする。
いろいろ Query を投げてみよう。
そもそも、REST を抽象化して ActiveRecord パターン似の API でやりましょう、
という ActiveResource がRails で提唱・実装されている。
その後、この ActiveResource の実装がいくつか公開されている中で、
クライアントライブラリの JavaScript 実装として有名なのが Jester 。
prototype.js, jQuery なんかの Ajax.foobar() を使ってゴリゴリやるのが今の日本の主流だと思うが、
WebOSGoodies で ActiveResource が絶賛されていることもあり、Jester で軽く試してみた。
prototype.js, jester.js をロードするだけの HTML を書く。
おもむろに使ってみる。find('all' {username: 'tonextone'}, console.log);
find(1274085406, console.log);
簡単です。お試しあれ。
]]>
OS のアップデート自体は、ほぼ無問題で、
ただ locale の調整が必要そうなので、それを今から解消する。
ports のアップデートも、無問題。
ports で、不用意に perl をアップデートしたので、少しはまった。
locale 問題を解消したら、
一連の詳細を trac に作業記録を書いて、このエントリからリンクする予定。
# trac も locale の問題でエラーを吐いているので。
ということで、 作業記録 。
]]>2008/05/15 : 通りすがりさんの報告を受けて、正規表現のパターンをさらに微調整しました。
2008/07/25 : Google 側のコードに変更があったようで、機能しなくなったので、 正規表現のパターンを緩めに調整しました。
2009/07/19 : kobuchi さんの報告を受けて、修正しました。
Google 側のコードの変更により /maps?file=api だけではなく、そこから先で動的にロードされる JS ファイルの内部も書き換えることが必要になったので、そのように変更しました。
http://maps.google.com/maps?file=api&v=2&key=...
っていう JavaScript を読み込むけれども、デモ: https://ssl.tonextone.com/neta/gmap_over_ssl/
# SSL の証明書を買っていないので、その旨の警告は出ます。プロジェクトチームでファイルを共有する場合、
このようなケースで、
User Private Group ポリシーを採用していない場合、つまり
のような場合、共有したくないファイルを作成するのが難しい。
普通にファイルを作成するだけで someone1:project の所有物となり、
umask(002) の効果で、自動的に project グループで共有されてしまう。
一方、User Private Group ポリシーを採用していれば、
普通にファイルを作成した場合は、 someone1:someone1 の所有物となり誰とも共有されず、
project グループで共有されるのは setGID されたディレクトリ内だけになる。
この違いが、重要な場合もあるだろう。
例えば、共有レンタルサーバの管理とかする場合は必須だろうと思う。