SPARQL Editorを自作する

ピン留めされたアイテム

kiai 2021/01/06に更新

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

WESP: EasySparqlProjekt 🐝

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

kiai 2020/12/14

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

kiai 2020/12/14

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

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

kiai 2020/12/14

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

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

kiai 2020/12/14

明確な目的を持った検索

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

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

kiai 2020/12/14

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

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

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

kiai 2020/12/14

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

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

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

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

kiai 2020/12/14

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

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

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

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

kiai 2020/12/14

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

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

kiai 2020/12/14

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

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

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

kiai 2020/12/14

フォームの仕様検討

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

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

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

kiai 2020/12/16

textinput

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

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

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