2010年06月20日

Google Documents List Data API v3.0 を python から利用してみた。

今更ながら、地味に便利なんじゃないかと思って試してみたら...

...すごい。
Google Docs と統合されたアプリを作ったり、単に HTML -> PDF などの変換に使えますね。

2009年04月18日

OpenLink iSPARQL で DBpedia をみる。

http://wiki.dbpedia.org/About
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 を 実行してみる。
2. product_developed_by_company_founded_in_California_advanced
(http://wiki.dbpedia.org/Datasets の 4.3.2. Querying the Infobox Ontology にあったサンプルです。 )

2. 結果をみる。
なにやら結果リストが表示されたのでみる。
3. product_developed_by_company_founded_in_California_result
(↑クリックで拡大しないとわからないが) Adobe の製品などが並んでいる。

3. SPARQL のグラフを視覚的にみる。
問い合わせを実行した後に、QBE タブに行くと、問い合わせの叙述が視覚化されている。
Advanced のフォームに SPARQL を書いて、実行しないまま Visualize ボタンを押しても視覚化できる。
逆に、 QBE タブで、視覚的に SPARQL を組み立てて、 Generate ボタンを押すと、Advanced のフォームでの編集モードになる。
1. product_developed_by_company_founded_in_California
問い合わせの叙述が、2 つのトリプルから構成させているのが、よくわかる。
# トリプルというのは { (Subject) −(Predicate)→ (Object) } のこと。

4. 結果リソースの関連情報をたどってみる。
結果リストから AdobeFlash を選択し、Get Data Items をクリックすると、
なにやら別の結果が表示された。
6. about_AdobeFlash_result

5. SPARQL を確認する。
4. about_AdobeFlash
↑こういうグラフで問い合わせが行われている。
つまり、
(Subject="AdobeFlash") −(Predicate=?)→ (Object=?)
和集合
(Subject=?) −(Predicate=?)→ (Object="AdobeFlash")

↓SPARQL で書くとこう。
5. about_AdobeFlash_advanced

なるほど。

Metaweb が Freebase 用に開発した MQL のほうでも、MQL Query Editorが公開されているが、
こうやってトリプルのグラフを視覚化して見せられると、SPARQL のほうが RDF / セマンティック 風味が強い気がする。
いろいろ Query を投げてみよう。

2009年04月04日

ウェブサイトのイメージを共有するためのツール

職場で、これから作成するウェブサイトのワイヤーフレーム + サイトマップを作りたくなって、いろいろ調べた際のメモ。

ワイヤーフレーム

pencilは、ワイヤーフレームというには、ちょっと具体的過ぎる感じ。
結局、ER図作成でお世話になっている gliffy を選択した。

gliffy は、矩形選択してコピーとか移動とかすると、
操作対象の中のレイヤーの z-index が維持されなかったりグルーピングがおかしなことになったりするけれど、
そういうクセを許容させるくらい使い勝手が良い。

また、今回の目的はイメージを共有することなので、
オンラインで共有できて、さらにコラボレーション(共同編集)できるのも良い。

サイトマップ

writemapsは、見た目キレイで良いのだが、機能が足りないので、却下。
dot -> graphviz も試したが、コラボレーションに向かないので、却下。
結局、マインドマップツールの、MINDOMOを使ってみた。
SERENA Prototype Composer も気になったが、ちょっと高機能過ぎる気がするのと、Windows アプリなのでコラボレーション的な制限を感じたので、保留。
今から触ってみます。

以上、とりあえずのメモ。

2009年03月08日

Jester is ActiveResource client lib. for Javascript.

JavaScript で REST API をたたく場合、
XMLHttpRequest, IFRAMEHttpRequest, JSONScriptRequest(JSONP) などを使うわけだが、
Jesterは、 これを抽象化して、xx.find(), xx.save() とかいうカッコいい API を提供してくれる。

そもそも、REST を抽象化して ActiveRecord パターン似の API でやりましょう、
という ActiveResource がRails で提唱・実装されている。
その後、この ActiveResource の実装がいくつか公開されている中で、
クライアントライブラリの JavaScript 実装として有名なのが Jester 。

prototype.js, jQuery なんかの Ajax.foobar() を使ってゴリゴリやるのが今の日本の主流だと思うが、
WebOSGoodies で ActiveResource が絶賛されていることもあり、Jester で軽く試してみた。

Firebug <=> Twitter API

とにかく手軽に試したいので、
  • Firebug のコンソール上で Jester を利用
  • 既存の REST API である Twitter API を操作
というプランで。

prototype.js, jester.js をロードするだけの HTML を書く。
1.load

おもむろに使ってみる。find('all' {username: 'tonextone'}, console.log);
2.find_by_username

DONE!
3.done

レスポンスの中を見てみる。
4.inspect

find(1274085406, console.log);
5.find_by_id

レスポンスの中を見てみる。
6.inspect_again

サーバとのやりとりを確認。
7.transports

要するに JSONP です。
8.jsonp

簡単です。お試しあれ。

2009年01月31日

FreeBSD リモートアップデート 5.4-RELEASE => 6.4-RELEASE

さくらで借りている専用サーバー(このブログも入ってる)の OS を、
リモートアップデートした。

FreeBSD 5.4-RELEASE => 6.4-RELEASE

5.4 用の ports のリポジトリが更新されなくなって来ている気がしたのが理由。

OS のアップデート自体は、ほぼ無問題で、
ただ locale の調整が必要そうなので、それを今から解消する。

ports のアップデートも、無問題。

ports で、不用意に perl をアップデートしたので、少しはまった。

locale 問題を解消したら、
一連の詳細を trac に作業記録を書いて、このエントリからリンクする予定。
# trac も locale の問題でエラーを吐いているので。

ということで、 作業記録

アーカイブ

フィード

このブログ

RSS 2.0 / ATOM

AdSense

del.icio.us

flickr