🌠

Eyjatto の紹介

2021/12/01に公開・約8,300字

Next.js

sparql

idea

この記事は klis Advent Calendar 2021 の２日目の記事です．前日はこっしーさんの研究室の入退室記録を（半）自動化した話 - 毎日こしたみんさん生活でした．

明日は _Makky_ さんの今年観た世界大会 2021 | blog.makky.io です．

それではお楽しみください

( ´ ー`).｡oO < 入退室管理マジで面倒なところは本当に面倒な制約になっていた時期があると私も聞いています．そこをさすがシステム主専攻出身，スマホのアプリと組み合わせて色々と解決策を模索したようです．鬱屈とした時代にこういうのを面倒臭がって家に引きこもると大抵良いこと無いので，いろいろな工夫でもって強制的にでも外出するのは大切だなぁと思います．

( ´ ー`).｡oO < いよいよポストコロナ時代が見えてきた2021年末，去年から今年にかけて本当にいろいろなことがオンライン上で行われるようになりました．しかしいくらそう言われても，いま私たちの多くは画面を通じて平面映像を視聴しているに過ぎません．俄に「メタバース」なんてものを騒がれ始めていますが，一体2022年はどのような一年となるのでしょうか？期待して待ちたいと思いました

はじめに

こんにちはこんばんわおはようございます，klis16 の Kiai です．気合のお兄さんと呼ばれた時期もありましたが今は見る影もなく(?)，日々人生と向き合っています．klis21 は未だおらんけど klis20 は既に学生生活２年目って認識で良いんすよね？時間の流れが早すぎて残酷だと感じるこの頃です．

追記

2021/12/14

アドベントカレンダーにおける本記事の「次の日」について記載
「はじめに」において不適切だった表現の削除
命名がまずかったので一部を変更（各位ごめんなさい）
form の設定記述を更新

つくったもの

さて，SPARQL をより扱いやすくするシステムとして Eyjatto を（暫定的に）つくりました．つくったから終わりということではなく，今後も継続的な改修を続けてより良い感じにしていく予定です（現状だと UI / UX ってやつがあんまりよろしくない……）．

関係者各位にぜひとも見て・使っていただいて，お褒め / お叱りの言葉を頂きたくおもいます．GitHub に Issue を立ててもいいですし，Zenn の Discussion 欄（本記事最下部）にコメントを残してくれるだけでも結構です．なにとぞよろしくおねがいします～～！

開発動機

前略

オープンデータ時代には機械可読性が大事なんだから CSV やら JSON やらをリポジトリに置いて悦に浸ってるんじゃねぇ！とは某所の師匠の言です．なるほど機械学習を始めとして読み取り速度が重要視される問題に関しては，手元にデータを置いてゴリゴリ弄るのは必要不可欠かもしれませんが，一方でセマンティック・ウェブ に寄与することまで視野に入れた場合，RDF: Resource Description Framework を採用しない理由はありません．
RDF でデータを記述する，すなわち Linked Open Data の原則に基づいて公開することでインターネット上に機械可読なデータを遍在させようというのがティムおじさんの大いなる野望の一つです．私も遠くない未来に機械学習関連の発展が（今のままでは）頭打ちになる^[1]と考えているため，その打開のためにもティムおじさんの考えを支持しています．

さて，そのオープンデータにアクセスするためには SPARQL と向き合わねばなりません．RDF クエリ言語の一つである SPARQL は W3C recommendation となっており，2021 年末時点でもデファクトスタンダードとなっています．初めて勧告になったのが 2008 年，2013 年にはヴァージョンが 1.1 となって再度勧告となっています^[2]．

けれども SPARQL は難しい！ SQL も覚束ないようなリテラシの学生であった自分が初めて SPARQL に触れたときはなんて複雑なんだと感じました．いまでこそそれなりに扱えるようになりつつあるとはいえ，ここまで習熟するのに相応の時間がかかったと思います．

「どうすればだれでも SPARQL が使えるようになるだろう？」

SPARQL を使ってオープンデータ時代をつくろうと叫ぶにも，そこには「SPARQL をうまく扱えるようになるべし」という強大な壁が立ち塞がっています．壁を超えられた人だけが仲間入りできるという状況では，裾野は広がらず山が高くなりようもありません．

だれでもいい感じに使える SPARQL 実行環境をつくろう！というのが，今回の出発点となっています．

要件

SPARQL クエリそれ自体は見えないように隠す
クエリの一部に穴を開け，そこにテキストを埋め込むようなフォームをつくる

誰でも使えるようにするには，〈実は裏側で使っているがそれに気づかせない〉というアプローチを取るのが最短だと考えました．そこから出発して，クエリ内部に穴をあける，すなわち変数を埋め込んでクエリ実行時にフォームの入力を取ってきて置換すればよいことに気づきました．

さっそくそんなライブラリやら OSS が既に存在しているかどうか調べます………ってもうあるじゃん！ということで SPARQList がどうやら使えそうな感じがします．さっそく調べました．

SPARQList

SPARQList は SPARQL クエリを実行し、その結果を JavaScript で加工して返すことのできる REST API サーバです。API の設定は Markdown 形式のドキュメントとして記述することができ、API のパラメータ、SPARQL エンドポイント、SPARQL クエリ、および、content-type negotiaion やデータ構造の変換のための JavaScript 関数を、自由記述の説明文とともに定義することができます。SPARQList サーバは複数の API を提供できるため、再利用可能な SPARQL クエリのドキュメント付きレポジトリとして活用することができます。

グワーッ！高機能ですごい！！ワイの仕事はこれを移植することだけや！ ……かに思われましたが，いざ使ってみると結局ほとんど「素人目線だと」何も解決してないことがわかりました 😢

「開発者目線」でのソリューションはすごい

SPARQL クエリをホストしておくリポジトリサーバとして活用することが出来ます．
加えて，そのクエリに対して API エンドポイントを定義してやることができ，これによりクエリの実行を肩代わりさせることができます．
（JS から外部オリジンへの直接的なリクエストは大抵が CORS 制限で弾かれる問題を回避してくれる）

また，帰ってきたデータを加工してから返すというミドルウェア的な処理も同時に記述できます．
これは SPARQL Query Result JSON の仕様そのままで返すよりも親切であるという見方もできるでしょう（サーバ側に計算リソースを負担させる）

もっとも特徴的かつ強みと言えるのは，これらをすべて Markdown 上で完結させているところです．

クエリの定義，API の定義，データ加工の JS スクリプト，すべてを一つのファイル上にまとめることが出来ます．
別途 RDB 等を用意する必要もないため，js の基本的知識さえあれば色々応用が効くような設計となっています．

※こちらから実際に SPARQList に触れることが出来ます．

実現せんとしていることの方向性は一致していましたが，これだと全然足りません．

フォームの柔軟性が皆無
受け取ったデータを表示するところまでサポートしてない
JS スクリプトを擬似ミドルウェア的に書けて嬉しいね～～とかセキュリティ的に危ないことするくらいならいっそ廃止したい

良くも悪くも，「SPARQL クエリ及びその処理をホストしておく」という機能に特化したシステムだったことがわかりました．言い換えれば，なんらかの応用をつくるための基礎にはなるかもしれませんが，これ単体ですべてうまくというビジョンは想像出来ませんでした……

でもこれをベースにいい感じにしたい！ → せや！ Next.js で自分好みに作り変えたろ！！！

Eyjatto

そういう経緯があって，~~"Next.js でつくる" , "次なる SPARQList" という思いを込めて~~ Eyjatto をつくりました．（追記 2021/12/14：名前で怒られそうということで変更しました）

Next.js を採用したことで， Vercel.app の無料サーバという環境がかんたんに使えることはもとより，SG の最適化による高度なパフォーマンスが期待できるようになりました．また旧 SPARQList と同様に RDB は一切使っておらず，もっぱら Markdown の記述だけで動きます．

柔軟なフォーム

Eyjatto では，「SPARQL クエリ」に加えて「設置したいフォームの設定」を記述できるようにしました．

そのフォームが対象とする変数名
フォーム種別
（入力値の候補）
（その他各フォームの持つ属性値）

を JSON コードブロックとして Markdown 上に置くことで，ビルド時に Next.js が設定を読み込んでページを生成してくれます．

現時点では，フォームは TextInput, Select, AutoComplete の三種に対応しています．

フォーム設定の例

endpoint: DBpedia Japanese に対してクエリを実行する
form: 入力フォームの設定；「オブジェクトの配列」となっていることからわかるように，フォームは複数設置できる

{
  "endpoint": "http://ja.dbpedia.org/sparql",
  "form": [
    {
      "element": "autocomplete",
      "param": {
        "name": "of",
        "from": "list",
        "keywords": ["東京都", "埼玉県", "茨城県"]
      }
    }
  ]
}

上記フォームの設定は，以下のクエリと対応している：

PREFIX prop-ja: <http://ja.dbpedia.org/property/>
PREFIX resource-ja: <http://ja.dbpedia.org/resource/>
SELECT DISTINCT *
WHERE {
  resource-ja:{{of}} prop-ja:隣接都道府県 ?prefecture_name .
}

{{}} で囲まれた of をクエリ実行時にフォームの入力値で置換することで有効なクエリへと変換する．

なお今回のクエリでは，入力した都道府県に行政境界を接する都道府県名の一覧が JSON で帰ってくる．

高機能なデータ表示テーブル

Eyjatto では，エンドポイントから帰ってきた JSON データをなるべくいい感じに操作して分析ができるようになっています．

こちらに関しては，実は私は殆ど手を加えておりません；代わりに MUI Data Grid くんが全部やってくれました．

具体的に私がやったことといえば，帰ってきた JSON を型安全に扱えるようにバリデータを作成したり^[3]，DataGrid くんがうまく扱えるように多少 JSON を事前加工する処理を書いた程度です．

さて，この DataGrid では結構いろんな事ができます:

カラム名をクリックすると降順・昇順の表示を切り替えられる
部分一致，完全一致，前方一致，後方一致でフィルタできる
各行を選択でき，選択部分だけを CSV エクスポートすることができる

※本当は他にも色々あるのですが，時間的制約の関係で現時点（2021-12-01）ではここまでしか実装できていません，あしからず……

TODO:

というわけで旧 SPARQList にあった不満は解消し，自分の求めていたものは最低限つくることができました．しかし，これだけではまだまだ広く一般に使ってもらえるようなシステムには到達していないと考えています（~~というか未だ UI 周りがクソすぎてダメダメじゃん，という指摘は許してクレメンス~~）

全体的な状態管理 ← Redux の導入
embed.js としてモジュール切り出し（フォームとテーブルをシステム外で独立して使えるようにしたい）
裏側のクエリを見られる＆編集できるようにする
- 仕組みを知れば，SPARQL への苦手意識も減らせる！（教育的アプローチ）
フォーム設定の仕様拡張
ただしいフォーム設定を記述するためのバリデータ OR エディタの作成
Markdown の fork 機能
全体的な UI/UX の見直し
全体的なリファクタリング

まだこれだけやることが山積みなのにお前〆切はどうなってるんじゃあ～と心配してくださる方もいらっしゃるかもしれませんが，ご安心ください！〆切が 2 週間伸び~~てしまい~~ました！
あと２週間で全部作り込んで出します！！！！！！！！！

LOD Challenge 2021

私が応募しようと奮闘しているのは，こちらの Linked Open Data Challenge 2021 (LOD チャレンジ 2021) です（ダイレクトマーケティング）．

LOD チャレンジ（Linked Open Data チャレンジ〈リンクド・オープン・データ・チャレンジ〉）は、オープンデータに関する新たなデータづくりやアプリケーションに関する作品を募集し、コンテスト形式で評価しあうイベントである。また、イベントを通じて、LOD の技術情報を発信するとともに、データやアイディアに関する情報交換や共有を行うコミュニティづくりを行う活動が行われている。
https://ja.wikipedia.org/wiki/LODチャレンジ

今年からは「データ作成部門」「データ活用部門」での募集となり，Eyjatto は後者での応募を目指しています．

おいおいコンペなのに応募前から宣言しちゃって良いのかよ～～とおっしゃる方もいるかも知れません．が，このコンペが面白いのはリアルタイムで応募作品が見られるところです（初見時にめっちゃウケてしまい全作品拝見しました笑）．リンク先の中ほどにある「現在の応募作品一覧」というボタンを押すと，すべての応募作品がまとめられたスプレッドシートを見ることが出来ます．

2021/12/01 現在，データ作成部門ではさながら群雄割拠の様相ですが，データ活用部門ではまだまだ作品数は多くありません．ちょうどあと２週間弱猶予があるので，もし興味を持った方いればぜひ応募してみてください！

脚注

良いデータ使ったもん勝ちな時代は終わり，これからはどう組み合わせるかになるはず，なってほしい（願望） ↩︎
もう 10 年経とうとしているのに，未だ人口に膾炙する機会の少ない SPARQL ですが，2010 年代の計算機の性能向上やそれに伴った機械学習ブームを鑑みると，多くの DS たちがそちらに熱中するのも致し方ない部分もあるかもしれません ↩︎
こちらの記事 → SPARQL のための型安全なバリデータをつくった（データ活用部門に応募済み） ↩︎

GitHubで編集を提案

Discussion

ログインするとコメントできます