辞書アプリの構造

みなさん、こんにちは。skytomoと申します。
この記事は、語学・言語学・言語創作 Advent Calendar 2024の23日目向けに書かれた記事です。

自分の作成している人工言語の辞書アプリ、Otamajakushi Bookshelfは、色々な形式の辞書を読み書きできるようにAPIを設計しています。私の辞書アプリがいつまで経っても制作中なのは、モチベーションの他に、この汎用性があります。今回は私の辞書アプリの構造を紹介し、後世の方が似たようなものを作成するときの参考になればいいと思っています。

BookとPage

Otamajakushi Bookshelfには、辞書を扱うためのデータ構造として2つの重要な構造があります。それがBookとPageです。

Bookは、その名の通り、辞書そのものです。Bookは以下のようなメンバーを持っています。

• 辞書の形式
• 辞書が固有に持つ情報
• 辞書のタイトル
• 辞書の説明
• 辞書のページ

そして、Bookのメンバーである辞書のページがPageです。

Pageは、辞書における検索可能な最小単位のデータのかたまりです。例えば、Wikipediaなら記事の一つが一つのPageに対応し、辞書なら一つの単語が一つのPageに対応し、コーパスなら一つの例文が一つのPageに対応します。
Pageは以下のようなメンバーを持っています。

• ページの形式
• ページが持つ情報

さて、このBookとPageさえあれば、Otamajakushi Bookshelfで読み書きできます。

BookLoaderとBookSaver

とはいえ、辞書ファイルは色々なものがあります。
日本人工言語コミュニティの代表的な辞書形式としてはOTM-JSON形式がありますが、他にもPDIC形式や、新シャレイア語辞典形式などがあります。これら3つの辞書形式のファイル構造についてすごく軽く触れておきます

• OTM-JSON形式
  • 1つのファイルからなるJSON形式のテキストファイル
• PDIC形式
  • 1つのファイルからなるバイナリファイル
• 新シャレイア語辞典形式
  • ディレクトリ形式と単独ファイル形式の2つの保存形式が定められている
  • ディレクトリ形式では1つのディレクトリで1つの辞典データを表現する
  • 単独ファイル形式では1つのファイルで1つの辞典データを表現する。

……さまざま形式がありますね。

Otamajakushi Bookshelfは、このようなありのままのデータ（以後、生データとします）を直接扱うことはできません。代わりに生データと、BookとPageの形式を相互に変換する機構が用意されています。

それがBookLoaderとBookSaverです。

BookLoaderは、辞書を読み込むための拡張機能です。生データを読み込んで、BookとPageの形式に変換します。

BookSaverは、辞書を書き込むための拡張機能です。BookとPageの形式を生データに変換して、辞書を保存します。

LayoutBuilder

実はBookとPageの形式に変換しただけでは、Otamajakushi Bookshelfは単語を編集することができません。それもそのはず、辞書アプリはページをどのように表示すればいいかわからないのです！

ページをどのようにレンダリングするかはLayoutBuilderという拡張機能が担います。
ページのデータと、ページのレンダリングを分離することで、辞書アプリのレイアウトを変えるときは拡張機能を入れ替えるだけでいいという利点があります。

その他の拡張機能

その他にもOtamajakushi Bookshelfは、いくつかの拡張機能とBookまたはPageのやり取りをして、辞書アプリとして機能します。

拡張機能の作り方

今のところ、websocket通信で拡張機能が動かせるようになっていますが、今後変えるかもしれないので、ここで述べることは避けておきます。

まとめ

まだOtamajakushi Bookshelfは開発中なので、仕様はコロコロ変わると思いますが、BookとPageというデータ構造、そしてそのデータ構造をいじるための拡張機能、というスタンスは変わらないと思います。

ボリュームが少なくて申し訳ないですが、今回はこんなところです。
24日目は、秋のカフェイン飲料さんです。いいお年を！