Zenn
Open12

SPARQL Editorを自作する

SPARQL
ピン留めされたアイテム
kiaikiai

このスクラップでは，思考をつらつらと書いていく．具体的な問題や計画は，Github Project 内で進行状況を書き出すようにした．

また，大きくなりすぎていた部分は「SPARQLogue」「Eyjatto」として切り分けた．

kiaikiai

ライフサイエンス統合データベースセンター が開発した上記３つのOSSを改造し，組み合わせることで新しい①SPARQL専用エディタおよび②SPARQLクエリ実行環境をつくる．これにより，SPARQLを解する者にとってはよりSPARQLクエリを編集・共有しやすく，SPARQLなんて何もわからないズブの素人であっても "SPARQLを解読せずとも" フリーテキストを用いたクエリ実行を可能にする．

kiaikiai

具体的には，まずSPARQL Supportをベースとしたオンラインエディタを開発する．SPARQL-doc形式（注：正式にこう呼ばれているのかは不明．またW3C等で制定されているものではない）を用いて「クエリの外から変数を注入」し，またその逆として「クエリ外部にフォームを自動生成」できるようにする．

次に，SPARQListのようにメタ情報を含んだMarkdownを作成できるようにする．クエリと結びつけることで，前述のエディタと一体化させることも考えられる．すなわち，Markdown＋クエリ＋フォームを同時に編集できるような画面を構成する．便宜上，この工程での構成物を SPARQLet と呼称する．

kiaikiai

ここまでで，①フォームを自動生成できるクエリ　②そのクエリに紐付けられたMarkdown　が得られた．次は，これらを活用して検索画面を作る．想定される検索意図としては以下のいくつかが挙げられる．

  1. 明確な目的を持った検索
  2. 名称だけ分かっている検索
  3. 目的も名称もあいまいな検索
  4. 複数のSPARQLetを対象とした検索
kiaikiai

明確な目的を持った検索

この場合，特定のSPARQLetを探してそのフォームから検索することが考えられる．

この検索を行なうユーザは，SPARQLetを探すための検索フォームが提供されることを必要としている．クエリ本体ではなく，Markdownを対象としたフリーワード検索ができるようにする．

kiaikiai

名称だけ分かっている検索

どんなふうに調べたらいいかわからないが，取り敢えず調べたい対象については分かっているという場合を考える．

SPARQLetを対象としてフリーワード検索でも良いが，それよりももっとクリティカルに「タグ検索」ができたほうがいいように思う．カテゴリ・タグ・子タグ…といった入れ子にして絞り込みができるようになるとなおいい．

kiaikiai

目的も名称もあいまいな検索

取り敢えずなんかキーワード入れてみるか～的な検索をしたいということも多々ある．

SPARQLetを横断してクエリを実行するためのフォームを用意するのはどうだろうか．そこにフリーワードを入力すると，それが代入可能なすべてのSPARQLetに注入され，（クライアントへの負荷も考慮しつつ）一定間隔で非同期にクエリが実行され，それが帰ってきた順に表示される．

（……RDFのエンドポイント側での負担が大きくなるが，それはまだ考えないでもいいように思う）

kiaikiai

複数のSPARQLetを対象とした検索

選択したSPARQLetだけを対象としてクエリを実行したい場合もある．これが実現できれば相当実運用に耐えるいいサービスとなることが期待できる．

SPARQLetとは別に，「SPARQLetをまとめたもの（バインドしたもの？）」という概念を導入すれば実現できそうな気がする．またそれも検索可能としておくことで，さらに利便性が広げられる気もする．

各SPARQLetのIDと，そこへ注入したいキーワードの配列（もとい，複数入力を考えると辞書であることが妥当）を用意してやれば良くて，仕様としてはこの配列さえもID管理できればDBに収めることができて良さそう（？）

kiaikiai

クエリからフォームを自動生成できても，その逆がまだ想定できていないことに気がついた．

といっても実装は単純で，フォームの状態をフロント側で追加した後，それをエディタ側の状態に追記してやればいいはず．追記すべき場所の特定が難しい可能性はいくらかあるので，そのへんの妥協点は見つける必要がありそう．

kiaikiai

各SPARQLetでのクエリを実行すると，それに対する返答が返ってくるはず．エラーなら何も表示しないが，運良くJSONが得られていれば，それを可視化するところまで考えたい．

単なるJSON文字列をParseして見やすく表示するだけでも良いが，せっかくなら d3sparql.js でうまいこと見えるようにしたい．

表示箇所の問題はあるが，各SPARQLetの内容物として表示できればそれで良い気もしている．

kiaikiai

フォームの仕様検討

sparqletの編集・検索段階で表示のやり方は変わってくると思うが，表示のための状態管理については共通のはず．
ただ，どういう順番で並べるか？　についてはきちんと考えておく必要があるようだ．

各フォームについて企画を統一する（例えばカードやパネルにしてしまうとか）のであれば簡単だが，フォームのカテゴライズによって表示が混ざるとよろしくない場合もある．それに，スタイリングの都合もある．

悩ましいが，まだ答えが出ない．取り敢えず，何も考えず並べてみることとする．

kiaikiai

textinput

デフォルト値： string | Array<string>
オプション：string（JSON） | Array<string>

デフォルト値がstringで与えられたときはそのままvalue属性へ突っ込む，Array<string>で与えられたときはインデックスが最も小さいものをvalue属性へ突っ込む．
配列に与えられた要素は入力候補として提示する．

オプションが Array<string>で与えられたときは，それをさらに配列に追加する．string(JSON)で与えられたときは，パースしてみて配列でないか確認したあと，配列なら同様に追加，連想配列オブジェクトならば任意の属性として突っ込む．パースできなかった場合は，オプションを表示せずエラーをだす．