Rails のアセットパイプライン（Asset Pipeline）について

アセットとアセットパイプライン

アセット（Asset）とは、 HTML ファイルに付随するCSS, JavaScript, 画像ファイルといった直接のレスポンスでないファイル を指します。

アセットパイプライン（Asset Pipeline）とは、 複数のアセットファイルをコンパイルし、1つのファイルに統合する ための仕組みのこと。複数あるアセットファイルを1つに統合することでクライアント側のリクエストを減らし、より素早いレスポンスを返すことができるといったメリットがあります。

Sprockets (Rails でアセットパイプライン機能を提供する gem) について

Rails におけるアセットパイプラインという仕組みは、 Sprockets と呼ばれる gem によって実現しています。

Sprockets は以下の機能を提供しています。

1. アセットファイルにアクセスするためのパスを管理する
2. アセットのコンパイル
3. アセットファイル同士の依存性の管理

1つずつ詳細を見ていきます。

アセットファイルにアクセスするためのパスを管理する

様々なディレクトリに置かれているアセットファイルのパスを管理し、 仮想的に1つのディレクトリにまとめて置いてあるようにクライアント側に見せる機能 です。

Sprockets の最も基本的な機能です。

例えば、普段開発を行う上で CSS ファイルは /assets/stylesheets に、 JS ファイルは /assets/javascripts という感じでファイルの種類ごとに分けてアセットパスを管理すると思います。これらの異なるディレクトリ下で管理されているファイル群を /assets に仮想的にまとめることができ、/assets/main.css というようにアセットファイルを参照することができるようになります。

Rails におけるアセットファイルの置き場所

rails new をした時点であらかじめいくつかのアセットパスが用意されています。

• app/assets …アプリケーションの主要な機能に関わるアセットファイル
• lib/assets …複数のアプリケーションで使われるような機能に関わるアセットファイル
• vendor/assets …外部から取得したアセットファイル

CoC （設定より規約）に反しないためにも、適切な場所に適切なアセットファイルを置くように心がけましょう。

config/application.rb でアセットパスの追加ができます。

アセットのコンパイル

JS や CSS のアセットファイルを コンパイル してくれます。元々 JS, CSS のファイルは何も起きません。

Rails ではデフォルトで CoffeeScript, Sass をコンパイルします。

例えば、 hello.js.coffee といった拡張子が連なって記述されたようなファイルを Rails でみかけたことがあるとおもいます。 Sprockets では拡張子からファイルの種類を判別しコンパイルします。この場合は、 hello.js.coffee は .coffee から CoffeeScript ファイルと判別しコンパイルして、最終的に生 JS ファイルとして出力されます。

この拡張子は 複数つけることも可能 です。

hello.js.coffee.erb というアセットファイルは、 ERB → CoffeeScript という順番でコンパイルを行い JS ファイルとして出力されます（後ろの方から順番にコンパイルが走る）。

コンパイルする種類は増やすことができます。

TypeScript を追加したい場合は、以下の方法で可能なようです。

Ruby on RailsでTypeScriptを使ってみよう！ | nanapi TechBlog

アセットファイル同士の依存性の管理

アセットファイル同士で起こる依存関係を『マニフェストファイル』と呼ばれるファイルで管理することができます。依存関係というのは、例えば hoge.js で jQuery を使ってる…みたいなパターンです。hoge.js は jQuery の機能を使っているので、 jQuery がないと動かない、つまり依存関係にあるということです。

rails new した時に作られるマニフェストファイルは app/assets/javascripts/application.js と app/assets/stylesheets/application.css になります。

実際に中身を見てもらうとわかりますが、 //=require jquery という記述があります。この記述がアセットファイル同士の依存性を管理している構文になります。コメント内で記述されているのはその他のツールで読み込んだ時に影響を与えないようにです。

require の部分は ディレクティブ と呼ばれ、 require 以外にも何種類かディレクティブがあります。その一部を紹介します。

ディレクティブ	説明
require	引数として与えられたファイルが自身よりも前に挿入される。2回目以降呼び出されても読み込まれない
include	require と同じ動きをするが、2回目以降呼び出されると都度ファイルの内容が挿入される
require_directory	与えられたディレクトリ以下のファイルを、自身よりも前に挿入する。順番はアルファベット順（さらに大文字→小文字）になる
require_tree	require=directory と同じ動きをするが、再帰的に読み込む

読み込みはコードの 上から順番に 読み込まれます。

Rails で生成したマニフェストファイルには //=require_tree . という記述があります。//=require_tree . はカレントディレクトリ以下の全てのファイルを再帰的に読み込んでいきます。自作したアセットファイルが自動で読み込まれるのは //=require_tree . がマニフェストファイル内にデフォルトで書いてあるからですね。

開発環境において、マニフェストファイルが正常に読み込まれているかデバッグするためのヘルパーメソッドがあります（stylesheet_link_tag, javascript_link_tag）。これを利用することでマニフェストファイルで読み込まれた順にアセットファイルが記述されていることを確認できます。

また、 config/environments/development.rb 内で config.assets.debug=true と設定しなければなりません（デフォルトは true）。false の場合は本番環境と同じく1つのアセットファイルに纏められます。

アセットファイルのプリコンパイル

リクエストが来た時点で事前にコンパイルしたアセットファイルを渡すことができる機能です。

$ rake assets:precompile

というコマンドでアセットファイルのプリコンパイルを行なうことが出来ます*1。

プリコンパイルを行なうことで、リクエストのたびにコンパイルをする手間が省けより効率的にレスポンスを返すことができるようになります。

Rails のデフォルトでプリコンパイルはしてくれますが、デプロイ時にプリコンパイルした静的ファイルを一緒にデプロイするのを忘れずに。

フィンガープリントについて

Sprockets でコンパイルされたアセットファイルは ファイル名-MD5 値.rb という形式のファイル名になります（例えば application.css のフィンガープリントは application-5eece9848f909164a45045f6a24bc6b1.css となる）。 MD5 値は元のファイルの内容から生成されたもので、これはファイルの更新があったかファイル名を参照するだけで済むというメリットがあります。

参考

書籍：パーフェクトRuby on Rails（p.94~104）

アセットパイプライン | Rails ガイド

*1:Rails 5 からは rake じゃなくて rails に統合されたんだっけ

universal-ctags で Vim からのコード参照を楽にする

備忘録

ちゃんと使えよって意味で

これはなに

関数やクラスの定義元にジャンプできるやつ。もともとは Vim に組み込まれていた機能だったが、バージョン6のリリースとともに独立したらしい。

正確に言うと universal-ctags とは、本家 ctags からフォークしたプロジェクトです。

Vim 以外のエディタでも ctags は使えます（Emacs, Sublime Text など）が、ここでは Vim についてのみ記述します。

作業環境

• OS X El Capitan (10.11.4)
• Vim (7.4.488)

インストール

GitHub リポジトリの README に記載されているやり方に従います。

github.com

github.com

$ brew tap universal-ctags/universal-ctags
$ brew install --HEAD universal-ctags

既に ctags を Homebrew からインストールしている場合は、アンインストールしておきます。

$ brew uninstall ctags

ctags でない理由

本家である ctags を使わない理由としては、2009年以降更新が途絶えているからです。

sourceforge.net

これでは最近生まれた言語（例えば Go 言語）では利用できないので、本家からフォークされた universal-ctags に移った次第です。

ここで回答している通り、 ~/.tags に書いても良いのですが、毎回これだと流石に辛いと思ったので……

universal-ctags は Go や Rust なんかをサポートしていますので良さがあるように見えます。

使い方

初めにプロジェクトのルートディレクトリで以下のコマンドを実行して tags ファイルを生成します。

$ ctags -R

-R オプションで再帰的にタグを生成しています。

git 管理下ではステージングファイルの候補一覧に表示されるので、 .gitignore に tags を追加しておきましょう。

定義元にジャンプする

関数やクラスのインスタンスにカーソルを合わせて <C-]> を押下すると、定義元にジャンプします。定義元が別ファイルにある場合は新規バッファが開きます。元に戻る場合は <C-t> です。

画面分割する場合は、<C-w><C-]> するとよいです。

g<C-]> すると、候補が1つの場合はそのまま定義元へジャンプし、候補が複数の場合は候補一覧を表示してくれます。

TODO

tags ファイルは新しく関数を作ったりする度に $ ctags -R で更新する必要があるので、自動化する。更新のタイミングとしては :w で保存する時、 git commit する時などがよさ気。

---

参考：実践Vim 思考のスピードで編集しよう！（書籍）

実践Vim 思考のスピードで編集しよう!

【Splatoon】ギアパワーの調整で今後使われていくかもしれないギアの紹介

こんにちは、mizukmbです。

本日（2016/03/04）のニンテンドーダイレクト放送内にて、 Splatoon 更新データ配信の発表がありました。

スプラトゥーンをプレイし続けてくれているみなさんのご声援により、もう少しの間だけ更新データの追加配信を実施することに決定した。
これから夏に向けてアップデートを行うので楽しみにして頂きたい。追加更新データ第1弾は来週3月9日配信だ。 pic.twitter.com/Pg05HPgFOM

— Splatoon（スプラトゥーン） (@SplatoonJP) March 3, 2016

ガチマッチの調整、既存のブキを改造した「ブキチセレクション」等これから夏に向けて順次配信予定とのことです。

その中から今回は ギアパワーの調整 についての説明と、今後、ガチマッチにおいて（もしかしたら）使われていくかもしれないギアを紹介したいと思います。

調整されたギアパワーたち

公式サイト内の情報によると、 2016/03/09 に配信される更新データにおいてギアパワーの調整がされるそうです。本記事執筆時が3月4日ですので、もうすぐですね。

どのギアパワーが調整されるのかはこちらを参照していただくとして、今回はその中から私が「ガチマッチで使えそう」と思ったギアパワーを紹介したいと思います。

逆転勝ちの可能性を高める『ラストスパート』

△ガチマッチでは、相手チームのカウントが30以下になった場合、それ以降継続して効果が発揮されるようにしました。

△ガチマッチでは、延長中も効果が発揮されるようにしました。

△これまでの効果に加えて、発動中は復活時間短縮の効果も発揮されるようにしました。

これまで、ナワバリバトル向きであり、ガチマッチだと全く役に立たなかったラストスパートがようやく実用性のあるギアとなりました。

ガチホコやガチエリアではのこり30以下になっても試合が続くことが多いので、恩恵を大きく受けられそうです。延長時間でも効果が持続するのは地味に嬉しいですね。

スペシャル増加量アップよりもいいかもしれない『逆境強化』

△発動中のスペシャルゲージ上昇速度を、これまでより20%速くしました。

やられた味方数だけスペシャルゲージの上昇速度が上がる『逆境強化』ですが、さらに性能が向上しました。やられないように耐え忍びつつスペシャルゲージを貯め、一気に優勢に持っていくという立ち回りができます。

『スペシャル増加量アップ』とどちらが効率が良いか？という研究や検証が Twitter 等でされてますが、 劣勢時にスペシャルを使って逆転を狙えるブキ（.96ガロンデコ、ホッカス、ノヴァネオなど） は『逆境強化』の方が良いかもしれません。

スーパーセンサーの攻撃的な対策としての『うらみ』

△これまでの効果に加えて、相手にマーキングされている間、攻撃力アップ・防御力アップ・ヒト移動速度アップの効果が発揮されるようにしました。

リッター3kやダイナモ等のスーパーセンサー持ちが多くいる現環境では、対策として『マーキングガード』をつけることがほぼ必須でした。そのせいで、『うらみ』の効果が微妙になりナワバリ・ガチマッチ共にあまりみないマイナーなギアという立ち位置でした。

しかし、今回の調整により スーパーセンサーにおける攻撃的な対策 として使えるギアになりそうです。

とはいえ、潜伏メインのブキでは使いにくいのでブキとの相性を見ながらという感じになりそうですね。

こんなギアがあったのか『ボムサーチ』

△これまでの効果に加えて、スプラッシュボム・キューバンボム・チェイスボム・トラップの、100.0未満のダメージ（※）を40％軽減し、クイックボムのダメージを20％軽減するようにしました。

※攻撃力アップや防御力アップの効果を計算する前に判定します。

スプラトゥーンを始めてから半年以上が経ちますが、 ガチマッチでは一度も見たことがない 『ボムサーチ』がかなり防御的な調整がされました。

『安全シューズ』との選択となるので、使われるかは正直微妙なところではありますが、防御ガン積み等の場合は使えるかもしれません。

CoD:BO の Perk にある「フラッグジャケット」ぽくなりましたね。

---

今回紹介したギアは一部ではありますが、調整が入ったギアは全て強化されています。しかし、今回の更新で今の環境が変わるかと言われれば…うーんって感じです。（『攻撃力アップ』にシールド破壊時の威力増大くらいの調整が欲しかった）

今後は、既存ブキを改造した「ブキチセレクション」の配信もありますので、 Splatoon はまだまだ長く遊べそうですね！

Splatoon ORIGINAL SOUNDTRACK -Splatune- (デジタルミュージックキャンペーン対象商品: 400円クーポン)

スプラトゥーン イカすアートブック (ファミ通の攻略本)

DBpedia Japanese を利用して各プログラミング言語の関係性を可視化してみる(実践編)

この記事はFUNAdventCalendar2015 9日目の記事です。

前回の続きとして、実際に DBpedia Japanese からデータの取得 を行いたいと思います。本記事を読む前にご一読頂けると今回の内容についての理解がより深まると思います。

前回の記事↓

mizukmb.hatenablog.com

それでは始めます。

DBpedia Japanese からデータを取得するために

前回ご紹介した DBpedia Japanese の RDF データから求めるデータを取得するために SPARQL を利用します。

取得するデータについてですが、今回のテーマである 各プログラミング言語の関係性を可視化 のために 影響を受けた言語 を取得しようと思います。 Ruby の Wikipediaページ(https://ja.wikipedia.org/wiki/Ruby) を確認すると infobox の項目に影響を受けた言語についての情報が掲載されていることが確認できます。

前回説明したとおり、 DBpedia Japanese では infobox の情報を RDF データに変換して持っていますので利用できそうなことが分かりました。

実際に SPARQL を利用してデータを取得してみようと思います。

Web 上で公開されている多くの LOD は データのアクセスポイントとして SPARQL EndPoint を持っています*1。ここに検索を問い合わせることで結果を得ることができます。

ちょっとやってみましょう。DBPedia Japanese の SPARQL EndPoint を見てみると、何か書かれてますね。 SPARQL は RDF の検索のために利用すること と 東京都 という文字があることから 東京都に関する情報を検索してくれそう と予想できます。とりあえず実行ボタンを押してみましょう。

どうですか。下の画像のような結果が出ていませんか?

無事 SPARQL を実行して結果を得られたようですね。おめでとうございます！👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏

ちなみにさっき実行した謎の文字列

select distinct * where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . }

これはおおまかに言うと 「東京都を主語として持つ述語と目的語の組み合わせを全て取得して下さい」 という意味になります。もちろんもっと細かい意味などはありますが、今回は雰囲気を掴んで欲しいので割愛します。

…ですが、 RDF の重要な項目について説明していなかった部分があったので補足します。

RDF はトリプルという 主語(Subject)、述語(Predicate)、目的語(Object) の3要素の組み合わせによって構成されています。 これらの要素は URI(あるいは IRI)を使用することが定められています。但し、目的語に関しては単純な文字列や数値(リテラル)の使用が許されています。 URI を使用することで コンピュータが参照可能なメタデータ** として扱うことができます。

雑な説明でしたが、本題に戻ります。

各プログラミング言語の関係性を可視化するぞ！！

今度こそ、各プログラミング言語の関係性を DBpedia Japanese から取得し可視化しようと思います。

前述のとおり、各プログラミング言語の関係性は 影響を受けた言語 をそれぞれのプログラミング言語から取得することで可視化していきます。

Ruby を例にすると

• 主語: Ruby(http://ja.dbpedia.org/page/Ruby)
• 述語: 影響を受けた言語(dbpedia-owl:influencedBy)
• 目的語:
• Lisp(http://ja.dbpedia.org/page/LISP)
• Perl(http://ja.dbpedia.org/page/Perl)
• 以下略

の主語と目的語群の組み合わせを取得します。ちなみに影響を受けた言語は必ずしも書かれているわけでは無いのであしからず。

そしてデータを取得するために利用する SPARQL クエリを予め用意致しました。

SELECT DISTINCT ?label ?influencedBy
WHERE {
  ?s rdf:type dbpedia-owl:ProgrammingLanguage;
  rdfs:label ?label.
  OPTIONAL {
      ?s dbpedia-owl:influencedBy ?ib.
      ?ib rdfs:label ?influencedBy.
  }.
}
ORDER BY ?label

こいつを先ほどの SPARQL EndPoint で実行することで結果を得ることができます。

どうですか。プログラミング言語の名前が沢山出てきたと思います。左側の言語が右側の言語の影響を受けているという風に読み取れます。

---

これで本来の目的である 『DBpedia Japanese を利用して各プログラミング言語の関係性を可視化してみる』 を果たすことができました。 LOD という仕組みはあまり知られてない上に利用する技術も多く大変です。ですが、 LOD 及びセマンティック Web がどういうものであるのかを今回の内容を通じて知っていただけたら私自身もアドベントカレンダーをやった甲斐があるというものです。

2回に渡る説明にこれまで付き合ってくださった皆様に多大なる感謝を申し上げると共に本記事を締めさせて頂きます。ありがとうございました。

付録: Graphviz を利用したデータビジュアライゼーション

今回の結果を更に見やすくするために、 Graphviz と呼ばれるグラフ作成ツールを使ったデータビジュアライゼーションを行いました。むしろここまでやって可視化といえるのでは。

使用言語は Python です。 Python から SPARQL クエリを利用するためにSPARQLWrapperを、 Graphviz を利用するためにPyGraphviz をインストールして下さい。

$ pip install SPARQLWrapper
$ pip install pygraphviz

そして下記コードを実行すると sample.pdf というファイルが生成されます。

gist913cc0156d328720cd8a

実際に生成されるファイルはこちらです。(画像がでかいのでリンクのみ)

グラフをどんどん辿れるのでこっちの方が可視化っぽいですね。

*1:持ってない場合もあります…

【小ネタ】GitHub の Gist などで画像を使用するために

メモ

GitHub Gist や README 等で画像を使用する場合はどこか別のサーバ(DropBox や imgur 等)にアップロードしなければなりません。

ですが、 issues ではドラッグドロップで画像を GitHub の画像サーバにアップロードできますので、あとは生成された URL を使えばおk。

上の gif は上記手法でアップロードしたもの。 URL 見てもらえばわかると思います。

念のためスクショを貼っておきます。

アップロードできたら消去しちゃってOK。

使い捨てでいいから画像を使いたいって時に便利。

2つの視点から見える井口祐未と安原絵麻の関係について

この記事は SHIROBAKO Advent Calendar 2015 6日目の記事です。

こんにちは、 @mizukmb です。

本題に入る前に、まずこちらのツイートを御覧ください。

明日というか本日12/6(日)はアニメーション神戸の授賞式です。SHIROBAKOは作品賞という大変名誉な賞をいただいております。https://t.co/10ZbjgXDbi #musani めがね

— TVアニメ『SHIROBAKO』公式 (@shirobako_anime) December 5, 2015

第20回アニメーション神戸にて、 SHIROBAKO が 作品賞 を受賞されました。おめでとうございます！🎉

こうやって SHIROBAKO が評価されることはファンとしてとても嬉しいですね。今後の展開にも注目です。

さて、本題に入ります。今回は『2つの視点から見える井口祐未と安原絵麻の関係について』お話します。

復習: キャラ紹介

もうわかってるよ！という方は読み飛ばしてもらって構いません

本記事の主役である 井口祐未 と 安原絵麻 を紹介します。

井口祐未

井口裕未（CV:沼倉愛美）

『えくそだすっ！』総作画監督補。若手の頃から小笠原に学び、経験を積んで今に至る。明るくはっちゃけたような口ぶりが特徴的だが、仕事に対する姿勢は真剣そのもの。その実力は小笠原と並び、武蔵野アニメーションの看板アニメーターとされるほどの腕前。

キャラクター｜TVアニメ「SHIROBAKO」公式サイトより

安原絵麻

安原絵麻（CV:佳村はるか）

武蔵野アニメーションの原画マン。 学生時代、あおい達と共に同好会でアニメを作っていた。 真面目だがおとなし目で引っ込み思案な面がある。 動画から一年半という短期間で原画に上がれたものの、 性格も相まって画のスタイルを決めきれず、悩み続けている。憧れのアニメーターは、日常芝居を得意とするなにわアニメーションの堀内さん。

キャラクター｜TVアニメ「SHIROBAKO」公式サイトより

武蔵野アニメーションでは彼女らは 先輩後輩の関係 にあります。

復習も済んだところでいよいよ『2つの視点』についてお話しましょう。

良き先輩後輩関係にある

前述のとおり彼女らは職場の先輩後輩関係にあるのですが、その関係が非常に美しく 「これ理想の先輩後輩関係では…」 とアニメを見てて思いました。

まず、第8話「責めてるんじゃないからね」 では絵麻ちゃんが猫の絵をうまく書けずに悩んでいるシーンがあります。井口さんは原画の先輩として自らの体験談を交えながら、 どうやって絵がうまくなるように努力したのか、煮詰まった時はどうすればいいか を絵麻ちゃんにアドバイスします。まさに理想の先輩像と言えますね。

さらに、 第16話「ちゃぶ台返し」では今度は井口さんがキャラデザインのリテイクで悩むシーンがあります。絵麻ちゃんは直接的なアドバイスはできないものの、バレないように会議室の扉の裏から盗み聞きする（小笠原さんにはバレていた模様）など井口さんを常に心配している様子 が描かれていました 。 かわいい 。

まとめると、

• 井口さんは先輩として、 後輩の悩みを聞き実体験を交えながらアドバイスをする
• 絵麻ちゃんは後輩として、 先輩の頑張りを陰ながらでも応援する

こんな先輩後輩関係、素晴らしくないですか？変な話。

私もこんな関係を築けるように頑張ろうと思いました。

中の人同士の仲がいい

ここからは中の人、つまり 声優 のお話をします。

彼女らを担当する声優は、井口さんが 沼倉愛美 さんで、絵麻ちゃんが 佳村はるか さんが担当なさっています。

沼倉愛美（愛称: ぬーぬー）さん

佳村はるか（愛称: るるきゃん）さん

彼女らは養成所の同期とも合って 非常に仲がいい ことで業界内では有名です*1。どれだけ仲がいいと言いますと、 佳村はるかさんを自宅に招いてお泊り会を開くほど だそうです。

そんなプライベートでも仲の良い2人が SHIROBAKO という作品を通じて共演なさっている。私はこの2人が絡む度に 『尊い…』 と思いながら観ていました。

ちょうど23話のラストシーンの2人が会ったあの感覚に近いです（ネタバレになるので伏せますが一度ご覧になった方は分かって頂けると思います）。

---

いかがでしたでしょうか。

本記事を通して井口祐未と安原絵麻の関係が如何に素晴らしく美しいものであるか伝わったでしょうか。

実は SHIROBAKO がオンエアされていた時期に私はちょうど就職活動を行っていました。私は SHIROBAKO から 働くことの意味や仕事にこだわりを持つ大切さを知り 何度も勇気をもらいました。その後、無事に内定を頂くことができました。

SHIROBAKO は私にとって人生を支えてくれた良きアニメでもあるのです*2。

これからも私は SHIROBAKO を応援していきたいと思います！

*1:我々の業界では『ぬーるる』と呼び広く愛されております

*2:言い過ぎ感

DBpedia Japanese を利用して各プログラミング言語の関係性を可視化してみる(座学編)

この記事はFUNAdventCalendar2015 4日目の記事です。

こんにちは、 @mizukmb です。

本記事では約2回に渡り LOD について紹介し、実際に LOD の技術を利用して各プログラミング言語の関係性を可視化してみようと思います。

対象読者

FUNAdventCalendar ということなので

• はこだて未来大学に興味がある人
• 研究テーマをどうしようか悩んでる学生

を対象としています。なので技術的な内容というよりは紹介メインな内容となっております。

LOD って一体なんですか?

LOD(Linked Open Data) とは、 世の中にある様々なデータを横断的且つ容易に利用できるようにするための仕組みのことです。

従来のウェブには膨大な量のデータが蓄積されています。このブログだってウェブ上に公開された貴重(?)なデータです。しかし、こうしたデータをコンピュータで処理しようとすると結構苦戦します。原因の1つとして、 データ形式の違い が挙げられます。 .html とか .csv とかそういうのです。 LOD は こうしたデータの形式を統一することで、データ同士がリンクする「データのウェブ」を目指しているのです。 LOD の普及が進むことで様々なデータを組み合わせた マッシュアップアプリケーション の構築が容易になるといったメリットがあります。

一見すると何も関連がなさそうなデータ同士を組み合わせることで新たな発見を促し、 データとしての価値を高める ことができるのも LOD の魅力といえます。

LOD を支える技術

LOD では セマンティックウェブ と呼ばれるプロジェクトの中で生まれたいくつかの技術を利用しています。言い換えれば、 LOD はセマンティックウェブプロジェクトの一種であるといえますね。今回はその中でも重要な技術である RDF(Resources Description Framework) と SPARQL(SPARQL Protocol and RDF Query Language) について説明します(といっても前述のとおりあまり詳しくは説明しません)。

RDF

データ形式の一種であり、要の部分でもあります。 RDF はデータを『 主語(Subject) 述語(Predicate) 目的語(Object) 』の3つの要素で表現します。これは RDFトリプル と呼ばれ、例えば『このブログの執筆者は @mizukmb である』という一文は

• (この)ブログ -> 主語(Subject)
• 執筆者 -> 述語(Predicate)
• @mizukmb -> 目的語(Object)

というように分類できます。このようにトリプルで表現できる情報を整理したものが RDF であり、その集合体(まさにデータのウェブ)が LOD であるわけです。

ちなみに、 RSS は RDF で書かれています。

SPARQL

SPARQL とは、 RDF データを検索/操作するための言語 です。つまり RDF データを扱うにはほぼ欠かせない技術ってことですね。

具体的な使い方については今回は說明しませんが、後々お話します。

Wikipedia + LOD = DBpedia

だいぶ駆け足で説明してきましたが、ついにタイトルでもある DBpedia Japanese についてお話します🍣。

DBpedia Japanese を一言でいうと『日本語 Wikipediaの情報を LOD 化したウェブサイト』です。といってもページに掲載されているすべての情報ではなく、ページ右側にある infobox を対象としているようです。

また、 日本語版だけでなく英語版などの DBpedia も存在します。 DBpedia の登場によって様々データがリンクしやすくなり LOD の普及に大きく貢献しました。

長くなりそうなので、今回はここまでにします。次回は DBpedia Japanese のデータを利用して各プログラミング言語の可視化を行おうと思います。

だいぶ端折った紹介になってしまいましたが、雰囲気だけでも分かっていただけたらありがたいです。最後に、 LOD 周りの研究について紹介して終わりとします。

未来大における LOD 及びセマンティックウェブの研究

未来大では大学の所在地でもある 函館市の歴史的文化財や観光情報 の LOD 化の研究が行われていたり、 高度 ICT 演習と呼ばれる PBL にて LOD を利用した アプリケーション開発 などに利用されたりしています。また、 LOD とは関係ありませんが RDF 等の技術を利用した研究もいくつか実績があるようです。

未来大以外の LOD 及びセマンティックウェブの研究・活動

ヨコハマ・アート・LODやデータ シティ鯖江など地方自治体の持つデータの LOD 化などの動きが高まっています。他にも、 既存の LOD を利用したコンテンストも毎年開催されています(LOD Challenge 2015)。

また、研究会としてセマンティックウェブとオントロジー研究会があります。

さらに最近では IoT(Internet of Things) の技術に RDF を採用するケースがふえているようです。(参考: 人工知能Vol. 30 No. 5( 2015 年9月)より Linked Data 活用を促進するプラットフォーム)