昨年市川市に引っ越してきてからCode for Ichikawaをやるのはどうかという話をしていたのですが、今年10月に色々な縁があり、とりあえず有志ではじめてみることになりました。最初の活動内容としては、個人的に行っていた5374 市川版のメンテと、複数のメンバーが興味を持ったウィキペディアタウンということにしました。5374については、codeforichikawaのレポジトリに移行中です。

もう1つのウィキペディアタウンについては、昨日11月3日に第1回ウィキペディアタウン市川と銘打って開催をしました。真面目な開催報告はCode for Ichikawaのサイトに書きましたのでこちらは個人的な感想を書きます。

間に神戸の国際会議運営があったために準備期間が短く、かなり苦労しました。対象を何にするかが一番悩みました。観光雑誌に載っているような有名スポット、例えば市川市の神社仏閣だと葛飾八幡宮法華経寺弘法寺とかは当然のようにウィキペディアにエントリがあります。ウィキペディアタウンをやる上では新規エントリ作成が満足度が高いと伝え聞くのですが、
会場の周りでまだエントリがないけど現地調査楽しめそうで参考文献も見つけられそうなものとかいう制約条件を充足するものを探そうとするとはまります。今回は会場が先に市川市文化会館に決まったので本八幡周辺で探すことになりました。調べていると市川市役所の神社にある「市内で神主が常駐しているのは葛飾八幡宮、白幡天神社の2社」という記述を見つけたので、これはきっと記事にできるくらいの何かがあるだろうという当たりをつけて、市川駅南口図書館にリファレンスをお願いしつつ自分でも調査をしました。

菅野から真間あたりは文学者ゆかりが多いようなので、文学者を中心に見るということをしたところ、幸田露伴・文親子や永井荷風が近所に住んでいて云々とかそこそこ面白いエピソードが見つかったのですが、肝心の神社自体の歴史があんまりよくわからずどうしたもんかなとおもっていましたがやはり図書館側でも神社自体の記述はそんなに見つけられなかったという話でした。勉強になったのは、ここら一帯は昔葛飾郡だったので、葛飾ほげほげという資料が色々役に立つということです。今後のウィキペディアタウン市川でも活用できるでしょう。

また、柴田是真の連句が千葉県指定文化財になっているとのことで、内覧をお願いできないかとおもっていたのですが、電話で問い合わせたところ、普段は可なのですが丁度七五三で11/15までは無理ですと言われてしまいました。完全に七五三とか失念していましたが、日を改めて個人的に見てこようとおもっています。可能なら撮影も。

総じてかなり事前準備が大変で当日までかなりやきもきしましたが、白幡天神社の調査がこちらの想像以上に参加者の方々に興味を持っていただけたようでその点が良かったです。執筆のほうも楽しんで頂けたようです。市外からいらっしゃってサポートや執筆ガンガンして頂いたウィキペディアンな方々や資料用意して頂いた市川駅南口図書館の館長さまにはお礼申し上げます。

無事終わった後の焼き鳥は美味しかったです。ウィキペディアタウンは継続して行っていきたいので、次の手を考えていこうとおもいます。

おまけですが、白幡天神社と併設の白幡天神公園について、OpenStreetMapでラベル等の項目追加をしました。OSMは正直まだアカウント作ったばかりで不慣れなのでこう直せとかマッパーの人優しく教えてください。とりあえずその項目ISO codeだよと直されているのは確認しました:)。市川市全然書き込みが足りていない感があるのでマッパーの方のご参加もお待ちしておりますというかOSM書く会もやれると良いですね。

この投稿にタグはありません。

ここ最近オープンサイエンスの流れをうけて研究データのオープン化とか研究データ論文とかがにわかに話題になっているのですが,まずは自分がやってみないとということで,手始めに人工知能学会全国大会の原稿用に作ったデータセットにDOIふるというのをやってみました.なんでもDOIをふってくれるサイトとしてはfigshareとかがありますが,今回はZenodoを使ってみることにしました.理由はGitHub連携が面白そうだったからです.

ZenodoのSign UpはGitHubORCIDのアカウント持っていれば簡単にできます.私の場合はGitHubアカウントで登録して後からORCIDにも連携しました.

利用の仕方は,直接アップロードするか,Dropboxと連携するか,GitHubと連携するかになっています.一回毎に2GBまでOKだそうです.対象種類に制限はなくて,論文,ポスター,画像,ビデオ,ソフトウェア等何でも可能です.

今回作成したGitHubのレポジトリは,fumi/dbpedia-japanese-usecasesになります.DBpedia Japaneseを利活用しているアプリケーション,データセット,研究のリストという内容のデータをTSVで作成しました.

Zenodo側でGitHubレポジトリの連携をするのが以下の画面です.GitHub連携すると保有するレポジトリの全リストが取得されるので,連携したいレポジトリを明示的にOnにすれば良いです.Zenodo

その後に,連携したGitHubのレポジトリのほうで,”Releases”をクリックします.

GItHubのリリース
GItHubのリリース

次画面で”Draft a new release”をクリックすると,GitHub上でのリリースを行うフォームになるので,バージョン番号とコメント付けて”Publish release”をします.そうすると,Zenodo側が自動で新リリースの内容を取得してDOIを振ります.リリースした中身は,Zenodoのメニューの”My uploads”から辿ることが可能です.Zenodo

連携がうまく行っていれば先程リリースしたバージョンのリンクが含まれているはずですのでクリックします.次にしなければならないのが,データについての項目の編集です.”Edit”ボタンを押すと編集ができます.GitHubからの連携だとカテゴリが”Software”になっているので,データセットに変更する必要があります.他の項目は,AuthorやLicense,Keywordsという定番のものからFunding, Publicationなど研究関係の様々な項目が設定できるようになっています.Zenodo上でコミュニティを作るということもできるようです.変更が終わったら”Submit”すれば完了です.

編集画面
編集画面

編集が終わった後のView画面が以下です.

ZenodoのView
ZenodoのView

右のDOIバッジをクリックするとMarkdownやらHTMLやらでの埋め込みコードが取得できます.わりとすごいのがCite asのプルダウンメニューで殆どの論文誌や学会のrefをカバーしているところです.また,BibTexやEndNoteなどの形式のExportもできます.

使っていて不便だった点は,リリースをする毎に新しいDOIが発行されるのですが,同じもののバージョン違いのDOIに何の関連もないことと,項目内容の引き継ぎがないので毎回項目を再入力しないといけないことです.これが地味に面倒.また,別の問題としては,リリースをしないとDOIが発行されないので,READMEにDOIバッジをはっている場合,前のDOIバッジのREADMEが含まれたままリリースされることになることです.これは些細な話ではありますがリリースファイルをダウンロードすると一貫性がなくて不思議なきもちになります.

総じて連携は簡単で,とりあえずなんでもDOIをはっていくには便利そうなのでしばらく使おうとおもいます.

これは SPARQL Advent Calendar 2015 9日目の記事です.

以前Wikidata Linked Dataという記事を書いた通り,Wikidata のデータ提供部分はLinked Dataです.これまでもサードパーティがそのRDFで勝手SPARQLエンドポイントを立てていたりしたのですが,今年9月にWikimediaが公式にWikidata Query ServiceというSPARQLエンドポイントをβ公開しました.今回はこれを使ってみようとおもいます.

サンプル例にアメリカ歴代大統領というのがあったので,試しに歴代の内閣総理大臣を開始年でソートするクエリを書いてみました(SPARQL例へのリンク).

PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX wd: <http://www.wikidata.org/entity/> 
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX psv: <http://www.wikidata.org/prop/statement/value/>
PREFIX pq: <http://www.wikidata.org/prop/qualifier/>
PREFIX pqv: <http://www.wikidata.org/prop/qualifier/value/>

SELECT ?primeMinister ?primeMinisterLabel ?startTime
WHERE {
   ?primeMinister p:P39 ?positionStatement .
   ?positionStatement ps:P39 wd:Q274948 ; 
                      pq:P580 ?startTime .
  
   SERVICE wikibase:label {
      bd:serviceParam wikibase:language "ja,en" .
   }
 }
ORDER BY ?startTime

結果は45件で,データとしてはかなり欠けています.明治・大正時代の人が全然いませんし,近年をみても麻生太郎と鳩山由紀夫が入っていません.皆で日本に関するデータを整備していく必要があります.

Wikidataのデータは多言語化前提になっていて,全てのリソースにIDベースのIRIが振られていて,そのIRIに対して多言語によるラベルを付与するというモデルになっています.そのため,リソースによってラベルがある言語がバラバラになるので,言語指定のフォールバックができる仕組みをSPARQLを拡張して用意しています.上記のクエリのSERVICE wikibase:label { ... }の部分がそれです.bd:serviceParam wikibase:language "言語名"の言語名の部分に複数の言語を指定すると,その順番でラベルを使用します.例えば”ja,en”であれば日本語が主で,日本語がない場合は英語を取得します.指定した言語がない場合はリソースのIRIになります.SELECTで指定する変数として,実際にラベルを取得したい変数の最後に”Label”を付けたものを指定することで,自動的にラベルを取得できます.上記例では,?president 変数のラベルとして?presidentLabelを指定しています.

この自動ラベル変換機能は一々言語毎にFILTERをするといった複雑なことをしなくて済むので便利ですが,いくつか制約があります.まず,OPTIONALで使っている変数は現在エラーになるようです(これはバグかもしれません).また,ラベルの中身に応じてフィルターしたいときのように,クエリ内で変数を参照したいときには使えません.その場合は,SERVICE句の中で直接rdfs:labelでラベル変数を指定すれば良いです.但し,自動変換機能と併用することはできないので,必要なラベルを全て指定する必要があります.

Wikidataまだまだこれからですが,色んなエンティティを結びつけるデータとしてどんどん整理されつつあるので,揃ってくればかなり期待できるサービスだとおもいます.

参考:

有志でSPARQLについての解説本をインプレスR&Dさんより出版しました.すでに電子書籍は本日付で発売となっています (Kindle版, Kobo版, iBooks版, Google Play版).何故かGoogle Playはいきなり1割引しているようです...紙の本は後日Amazon.co.jpのプリント・オン・デマンド発売される予定です.

これはCivic Tech Advent Calendar 2014の19日目の記事です.

最近,Open Parkというプロジェクトを勝手にはじめてみました.直接のきっかけは,公園の禁止事項がどんどん増えているのを見て,そもそも地域の公園情報が全然共有されていないと感じたことでした.単純にボールを使って遊びたいと思っても,できる公園を探すのが大変です.大きい運動公園くらいになると検索サイトがあったりするのですが,住宅街の中の公園は殆ど何もなく,多くの場合は現地の掲示板や看板にのみ許可や禁止が書かれています.内容は法律や条例で禁止されているものからマナーまで様々です.最初は自治体がこの手の情報を全て管理しているのかと想像していたのですが,実はそうではなく愛護会のように地域住民のボランティアで成り立っている部分がかなりあることがわかりました.そこで,地域の公園データを収集・公開・共有できる場所が必要なのではないかと考えました.

公園看板
公園看板

とりあえず試作してみようということで,主に横浜市金沢区のオープンデータを利用して,Open Park Yokohamaというのを作ってみました.横浜市金沢区を最初の例として選んだ理由は,公園関連のデータが既にいくつか公開されていたためです.

現在Open Park Yokohamaでできることは,地図から公園を探すのと遊具の種類で探すことだけです.各公園のページでは,公園の基本データと,公園にある遊具や看板写真等を載せています.写真については手始めに30ヶ所程度の公園を撮影してきましたが,金沢区全域で190の公園があるので1/6程しかカバーしていません.

寺前さざなみ公園
寺前さざなみ公園

技術的な話としては,データは主に共通語彙基盤のコア語彙2.10Schema.orgをベースに設計をしてあります.一応現在のデータ用のSPARQLエンドポイントも出していますが,今後データ設計は変える予定ですのでお試し程度ということで.Linked Data対応等のAPI充実化はする予定です.

今取り組んでいるのは,公園写真を増やすことと,それらの写真から禁止事項や許可事項をデータ化して禁止・許可事項データを作ることです.やってみると結構大変で,公園毎に表現がバラバラだったり曖昧だったりします.顕著な例としては上の看板にある「危険な球技」や「危険なあそび」というのです.公園毎に「危険な球技」として列挙されている球技が異なりますし,そもそも「危険な球技」が何かがわからないので判断に困ります.これが,数を集めるとわかったりするのではないかと期待しています.全国でやってみると地域ごとの傾向があったりするかもしれません.

将来的には市民を巻き込んで発展していく仕組みが必要だと考えています.例えば横浜全体でやろうとすると公園が2000近くあるそうなので,スマートフォンで写真をアップロードしてもらったり,データを入力してもらったりして効率よく収集する仕組みがあるといいでしょう.OpenStreetMapで公園データを充実させて利用するというのもありえます.うまく全国で集められるようになると面白いなとおもっています.

オープンデータ活用コンテスト___未来とメトロ___東京メトロ 10th anniversary

以下はFacebook上での議論をまとめたものです.

東京メトロさんは以前から”オープンデータ”を行うという宣伝をしていたのですが,昨日やっと概要が公開されました.企業がオープンデータを出してその活用コンテストも行うというのは大変素晴らしいことで,何より多くの人が興味を持ちやすいデータですので是非応援したいし,できれば何かアプリを作りたいなとも思っています.

しかし,現在の応募規約について様々な疑問がでており,これはオープンデータではなく単なるAPIコンテストになっているのではないかという懸念があります.ちなみにこの規約のページは何故かPCのブラウザからは404 Not Foundですが,スマフォのブラウザからは見られるようになっています (PCからもヘッダ変えると見られます)

上から順番に見ていきますが,まず,“応募作品は、応募者が考案・開発したものであり、全ての著作権を有しているものに限ります。”とありますが,オープンデータを活用するのが前提である以上,データの部分の著作権は応募者が有していないことが殆どであるかとおもいます.ソフトウェア部分の著作権について述べていると解釈するのであればわかります.(追記: ソフトウェア部分もオープンソースのライブラリ等使ったら駄目ということですかね.)

次に“オープンフリーで利用できる他データの組み合わせは可能とします。(例、twitter API、yahoo API、など)”とありますが,オープンフリーの定義がわかりません.例として挙げられているtwitter APIやyahoo APIは少なくともオープンデータではありませんので,オープンフリーが何を指すのか明らかにして頂かないと応募者はわからないのではないでしょうか.

3つ目として,これが一番重要ですが,“応募者は、データ等を本コンテストへの応募作品の開発及び本コンテストの応募以外の目的で使用してはならないものとします。”とあります.オープンデータと謳うのであれば,このような目的外利用の制限はおかしいです.“応募者は、データ等及び本コンテストへの応募作品を、有償か無償かに係らず商業目的には利用できないものとします。”というのも同様です.

繰り返しますが,試み自体は大変素晴らしいことですので,東京メトロさんには是非オープンデータという単語を誤用せずに正しく理解した上でコンテストを行なって頂ければと切に願います.

OS Linked Dataの行政区画は,Office for National Statistics(日本の統計局か統計センター?)のONS linked data portalにつながっています.例えばBoundary-Line Linked Dataの記事で取り上げた Haggerston のデータには,以下のリンクがあります.

<http://data.ordnancesurvey.co.uk/id/7000000000011110> <http://www.w3.org/2002/07/owl#sameAs> <http://statistics.data.gov.uk/id/statistical-geography/E05000239> .

ONS linked dataでは,統計上の区画を全てstatistical-geographyクラスのインスタンスとしています.これはOS Linked Dataとは異なる設計です.ここでは,OS Linked Dataから見て,HaggerstonとONS linked dataにおけるHaggerstonが同じである(owl:sameAs)というリンクをしています.以下の図は前回の図からONS linked data portalへのリンクを追加したものです.

OS Linked DataとONS linked data
OS Linked DataとONS linked data

基本的にはONS linked data portal上にも各行政区画に相当するstatistical-geographyが記述されており,その包含関係も記述されています.一つ面白いのはLondonです.Londonには行政区画としてのLondonとEuropean RegionとしてのLondonが記述されており,OS Linked DataのLondonからのowl:sameAsリンクはEuropean RegionとしてのLondonにされていますが,ONS linked data portal上での行政区画の包含関係は行政区画としてのLondonを使うようになっています.これは意図して行っているのかが不明でもしかしたらミスかもしれませんが,意図しているのであれば明示的に役割によってLondonをURIで区別して利用している例だと言えます.