Add YAML/JSON formats

[tani]

旧辞書フォーマットはメンテナンス性や読み込み速度の面で改善の余地がありました． そこでSKKの利用者や開発者から新しい辞書形式の策定が望まれていました．

このプルリクエストの作者は実験的にYAML形式とJSON形式の辞書を作成しました． JSON Schemaを同梱し仕様に合致しているかを検証できるようにしています． 私としては暫定的にこの仕様を採用していただき， 今後の議論によって仕様の更新が発生した場合は その都度仕様のバージョンをインクリメントするようなやり方だとスピード感をもって 作業をすすめられると提案致します．

• [x] SKK-JISYO.JIS2.yaml
• [x] SKK-JISYO.JIS2004.yaml
• [x] SKK-JISYO.JIS3_4.yaml
• [x] SKK-JISYO.L.yaml
• [x] SKK-JISYO.M.yaml
• [x] SKK-JISYO.ML.yaml
• [x] SKK-JISYO.S.yaml
• [x] SKK-JISYO.assoc.yaml
• [x] SKK-JISYO.china_taiwan.yaml
• [x] SKK-JISYO.edict.yaml
• [x] SKK-JISYO.edict2.yaml
• [x] SKK-JISYO.emoji.yaml
• [x] SKK-JISYO.fullname.yaml
• [x] SKK-JISYO.geo.yaml
• [x] SKK-JISYO.hukugougo.yaml
• [ ] SKK-JISYO.itaiji.JIS3_4.yaml
• [x] SKK-JISYO.itaiji.yaml
• [x] SKK-JISYO.jinmei.yaml
• [x] SKK-JISYO.law.yaml
• [x] SKK-JISYO.mazegaki.yaml
• [x] SKK-JISYO.okinawa.yaml
• [x] SKK-JISYO.pinyin.yaml
• [x] SKK-JISYO.propernoun.yaml
• [x] SKK-JISYO.pubdic+.yaml
• [x] SKK-JISYO.station.yaml

ＪＩＳ３_4系は文字コードの都合上， EUC-JP -> Unicode間で欠落が生じるため旧フォーマットのままとしています．

[tkita]

議論の流れを理解していないのですが（そもそもどこで議論されているのでしょうか）、 各種skkプログラムは、YAML形式辞書やJSON形式辞書を直接読み込んで使用できるのでしょうか、 それとも、いったん現行フォーマットへ変換してから使用するのでしょうか。 後者だとすれば、その変換はどのように行うのでしょうか。

[tani]

お返事ありがとうございます。議論は以下から追うことができます。https://github.com/skk-dict/skk-dict/discussions

このプルリクエストを作ったときから、だいぶ議論が進み、現在はyaml形式ではなくjson形式の配布を検討しています。

辞書の変換については、すでにvimのskk実装であるskkeletonが直接読み込みに対応しています。 emacsもnativeでjsonの読み書きができるようになって久しいので、ddskkもjson版辞書を読み込めるようにするのは難しくないと思います。そして、tani自身もそのプルリクエストを書く意志があります。

現辞書形式を使い続けたい人のためにjson版から現辞書形式に戻すための変換器（github.com/skk-dict/jisyo）も用意しています。必要があればCIを回すことで、同時に配布ができると思います。

[tkita]

返信ありがとうございます。skk-dict すごいですね。

本 PR を merge する方向で構わないのですが、以下についても commit していただけると嬉しいです。

• 現行辞書ファイルを legacy ディレクトリに移したら make 通らなくなるのでは
  • Makefile 修正 又は legacy ディレクトリに移さない
• README の修正
  • skk-dict との関係性
  • json 形式辞書の位置づけ
  • json 形式辞書の使い方

[tkita]

調べずに投稿します（すみません）。

もしかして、json 形式辞書に対する検索って「問い合わせ」が可能でしょうか。 （見出し語をキーとして「問い合わせ」すれば、候補群が返ってくる）

elisp で実装している二分検索（バイナリ・サーチ）が不要になるなら、辞書ソートも不要になるため、とても興味が沸きます。

[tkita]

いったん merge しましたが、もう少しお教えください。

• 配布物の生成方法
• 配布場所
• メンテ方法（旧形式と自動同期？　独自にメンテ？）

[tani]

マージありがとうございます。お返事が遅くなり済みません。 まず始めに、未だ作業中でした。誤解を招いてしまいすみません。 未マージとなってしまった内容は以下の通りです。

• 変換スクリプトの同梱
• Makefileの更新 (txt -> json の同期)
• READMEの更新

追ってプルリクエストを開きます。お手数をおかけしますが、よろしくお願いします。

---

さて、長文になり恐縮ですが、ご質問を順に回答させてください。

json形式の辞書に対する問い合わせ操作について

見出し語から変換候補を引くことは可能です。なぜなら、emacsのjsonパーサーはJSONファイルからハッシュテーブルを返してくれます。そのため、よくあるプログラミング言語の様に、適当なキーで索引を引くと、候補の配列が返ってきます。

配布物の生成方法

生成スクリプトも同梱します。make json で生成できるように致します。

配布物の生成方法

github pagesにて配布できるよう、gh-pagesブランチにもプルリクエストを送ります。

メンテナンス方法

GitHub Actionsで gzip 版や json版が 自動で配信できるようプルリクエストをお送りします。

今後について

ここまで長期に続いているプロジェクトであれば、 メンテナンスについて独自のルーティンや文化があると思います。 その文化を尊重した上で、相談させていただきたいことがあります。

• 現段階では txt -> jsonで生成することで配布をする。しかし、今後は
• JSON形式の仕様 (JSON schema)について、互換性を保ちつつ、開発者/ユーザーが使い安いように改良をする議論の場を skk-dev 内に作りたい。
• 仕様が十分に成熟した段階 (全ての辞書をJSONに移行できたとき？)に、JSONを元データに据えて、txt版の辞書を生成する形で辞書をメンテナンスするようにしたい。
  • これは、エントリ追加のプルリクエストが届いたときにJSON validatorで自動でレビューすることで、追加の手間を減らしたいからです。