Nota、学術論文とブログ記事のためのブラウザ文書言語

 (nota-lang.org)
2 ポイント 投稿者 GN⁺ 2023-10-21 | 1件のコメント | WhatsAppで共有
  • PDFと静的Webページの限界を超え、文書構造をブラウザが理解し、読者が直接活用できるようにする文書言語を目指している
  • Nota文書はJavaScriptプログラムにコンパイルされてブラウザで実行され、文書作成に変数・関数・データ構造を活用できる
  • KaTeX、Vega-Lite、PenroseのようなJavaScriptライブラリ統合と、アクセシビリティ要件への対応を念頭に設計されている
  • @nota-lang/notaパッケージでnota実行ファイルをインストールし、ビルドや対話型編集のフローで文書を扱える
  • まだ新しく変化の途上にある技術であり、アーキテクチャやAPIが変わる可能性があり、ツールや文書のバグ・欠落・不正確さを考慮する必要がある

ブラウザが理解する文書構造

  • Notaは学術論文やブログ記事のような文書を書くための言語である
  • 目標は、文書を21世紀型のメディアへと持ち込むことにある
  • 文書の中には、用語の定義や参照のように、読者がたどるべき構造が多く含まれている
    • たとえばNotaという単語は、前の段落で定義された用語を参照している
    • Notaは著者がこうした構造を表現できるようにし、ブラウザがそれを理解して読者が活用できるようにする
    • 例示ページでは、Nota参照をクリックまたはダブルクリックして動作を確認できる
  • Nota文書はJavaScriptプログラムにコンパイルされる
    • Webブラウザのあるあらゆるデバイスで文書を閲覧できる
    • 変数、関数、データ構造を使って文書作成を簡潔にできる
    • KaTeX、Vega-Lite、PenroseのようなJavaScriptライブラリと統合できる
    • スクリーンリーダーのようなアクセシビリティ要件を支援しやすい

インストールと編集フロー

  • Notaは@nota-lang/notaパッケージでnota実行ファイルをインストールして利用できる
    • 必要条件はNodeJS ≥ 16とnpm ≥ 6である
    • NodeJSのグローバルバイナリディレクトリがシェルのPATHに入っている必要がある
  • 単一のNota文書は次のフローでビルドできる
    • npm install --global @nota-lang/nota
    • echo "@Title: Hello world" > index.nota
    • nota build index.nota
    • open dist/index.html
  • Notaファイルはnota edit index.notaコマンドで対話型編集できる
  • 文書の書き方はReferenceで確認できる
  • WebサイトにNotaを追加したりアーキテクチャを確認したりするには、Integration guideを参照するとよい

PDFと静的Webのあいだのギャップ

  • デジタル文書の主要な媒体はPDFとWebページに分かれている
    • PDFは物理文書を反映するよう設計されており、ページ分割、固定幅、変化しないスタイルといった紙の制約を持つ
    • Webページは、スマートフォン向けのサイズ調整、他言語への翻訳、色覚異常のある利用者向けの色変更のような動的フォーマットが可能である
    • Webページは、より多くの文脈を求めるテキスト、視点が変化する図、後のための注釈といった動的インタラクションも可能である
  • こうした動的機能は、現在のところ主に専門のWeb開発者にしか手が届かない
    • LaTeX、Pandoc、Markdown、Scribbleのような既存の文書ツールの多くは、静的なWebページしか生成できない
    • Notaは、低い参入障壁、高い拡張上限、なだらかな学習曲線を備えた文書言語として、そのギャップを埋めようとしている

現在の状況と参考資料

  • Notaはまだ新しく進化の途中にある技術である
    • アーキテクチャとAPIは継続的に変化している
    • ツールにはバグや未実装の機能がある可能性がある
    • 文書は不完全または不正確な場合がある
    • 現在は、Notaを未来の文書言語にすることに参加する初期ユーザーを募っている
  • @Definitionと@Refコンポーネントは、著者が少量の文書注釈を追加するだけで、Notaランタイムが参照先の定義をツールチップとして文脈内に表示できるようにする
    • 将来のNotaバージョンには、特定の定義へのすべての参照を探すといった機能が含まれる可能性がある
  • 設計思想についてはA New Medium for Communicating Research on Programming Languagesで詳しく見られる

関連記事

1件のコメント

 
GN⁺ 2023-10-21
Hacker Newsのコメント

  • Notaを作っている者ですが、Webページの初期プロトタイプ以降、設計をあらためて磨き直しているところです
    コンテンツと計算をどう混ぜるか（https://arxiv.org/abs/2310.04368）、構文が文書作成をどう簡単／難しく／不可能にするのか（https://github.com/cognitive-engineering-lab/doclang-benchma...）といった問題について、より堅固な基盤を作っています
    大きな哲学は今でも信じていますが、Notaは約6か月以内にかなり変わると思います。その間、文書言語の分野で最もクールな進展はTypstだと見ているので、ぜひ確認してみてください: https://typst.app/
    次のNotaのバージョンは99% Rustで書かれる予定です :-)

    • 言語の選択よりも、APIを幅広いユーザー層にとって使いやすくすることのほうが重要に見えます
      パフォーマンスが本当に問題ならRustはJavaScriptより理にかなっていますが、ほとんどのユースケースで決定的かどうかは分かりません
      LaTeXは大きな文書でたくさん使ってきましたが、好きになったことはありません。学術向けの怪物という感じで、ビジネス向けではありませんでした。Wordでも一貫してやりたい作業が常に簡単とは限らず、スタイルはすぐにぐちゃぐちゃになり、番号付けや箇条書きにもエラーが入り込みやすいです
      複数回の改訂が行き来すると、変更履歴が大きな問題になり、結局は相手が履歴を上書きしないという信頼に頼ることになります。最初から最終承認まで、すべての変更がきちんと見えることを保証する製品だけでも、企業や弁護士が喜ぶキラーアプリになり得ます
      ここにブロックチェーンを振りかければ資金調達は簡単になるかもしれませんが、実際にはブロックチェーンというより基本的な暗号学の問題に近く、その程度の複雑さは必要ないように見えます
    • 学術関係者として、時間の99%は2つのことに使っています。RやPythonのような言語で統計計算を書き、英語のテキストを書くことです
      文書言語で最も重要なのは、この2つを優先することです。たとえばTeX文書は\documentclass、複数の\usepackage、theorem定義、フォント設定といった準備コードから始まりますが、R Markdown/Quarto文書はタイトル、著者、要旨といった実際の文章の意味からすぐに始まります
      重点の違いがはっきり見えます
    • Notaが、TeX/LaTeXでは理論上は可能でも実際にはうまく解決できていない問題を解決できるなら面白そうです。つまり、ばかげた外部要件に合わせたスタイリングの容易さです
      A0学会ポスターのような窮屈で情報量の多いレイアウト、旧ソ連圏のGOSTのような国家標準の文書スタイル、国際的な伝統ごとに爆発的に増える参考文献スタイル要件、特定のMS Wordバージョンのデフォルトスタイルのように見せること、論文で素早く修正するために図の上へ図やテキストを精密に配置すること、こうしたものを意識的に調整することなどが含まれます
      TeXの世界では技術的にはすべて可能ですが、実際には学位を持つ一般ユーザーでさえ深入りしたくないほど深い黒魔術が必要です
    • Notaは良さそうです。Knuthの「文芸的プログラミング」から取ったLiterate Markdownという似たものを作っていて、最初から計算と説明を混ぜることに焦点を当てていました
      ここ数か月、SVGアニメーションのアイデア（https://simpatico.io/svg）を探ったり、新しいデータ構造／アルゴリズム（https://simpatico.io/stree3）を具体化したりするのに楽しく使ってきました
      サーバー全体とMarkdown処理系は読みやすいNodeコード約500行で、依存関係は非常に少なく、推移的依存関係はなく、コンパイル段階も不要です。基本的にサーバーは第三者リソースやCookieを一切許可しません
      MITライセンスでGitHubにあり、個人リポジトリから組織リポジトリへ移しながら整理しているところです。参考: https://simpatico.io/lit
    • 興味深いことに、こうした問題やそれ以上のことはOrg Modeでかなり合理的に解決されています。ただ、Emacsを使う人が少なすぎるので、知っている人も少なすぎます

  • 「不可欠な動的性」が不要な場所では、むしろそれがないことこそ機能であって、バグではないと思う

    • 完全に同意。動的性はWebアプリには素晴らしいが、文書では最も望ましくないもの
    • 小さな画面、特にモバイルでPDFを快適に読むには、基本的な動的レイアウトは必要に見える
      モバイルではPDFよりWebページを読むほうをはるかに好む。まともなWebページなら普通、モバイル画面に合わせられるから
    • PDFはデジタル上で再現される方法を制限することで情報を制約している。PDFでは「ただ」コピー＆ペーストすることはできず、奇妙なエラーだらけなので、テキストを大幅に再整形するか、特殊なソフトウェアを通す必要がある
      視覚情報とデジタル情報を一緒にエンコードする形式が必要。デジタル層は通常は見えなくてもよいが、必要なときにアクセスできるべき
    • AdobeのPDF仕様は、意外にもJavaScriptの実行（https://helpx.adobe.com/acrobat/using/applying-actions-scrip...）、インタラクティブな3Dグラフィックス（https://www.youtube.com/watch?v=PKfyFt3zT5A、https://www.youtube.com/watch?v=vW5-1LVtd9U）、音声と動画（https://helpx.adobe.com/acrobat/using/rich-media.html）、レスポンシブPDF文書向けの「Liquid Mode」（https://www.adobe.com/acrobat/hub/what-is-adobe-liquid-mode....）までサポートしている
      もちろん、こうした「機能」は長期保存用のISO PDF/A仕様ではバグと見なされ、取り除かれている: https://en.wikipedia.org/wiki/PDF/A
      要点は、文書は時にただの文書であるべきだということ。科学論文では、LaTeXは人が人のために書くもので、カスタムコマンドやパッケージのおかげで、生成された論文と同じくらい読みやすい平文ドキュメントを書ける。アクセシビリティの面でもよい
    • PLDI論文の例を見ると、大きく密な数式内の記号にポップアップ説明が付いている。こういうものは本当に役に立ち得る
      動的文書には興味深い未開拓領域があるが、品よく使っている良い例が必要

  • 要約するとLaTeX寄りで、Markdown要素も一部あり、JavaScriptで書かれているので多くの人が既に知っている言語で貢献でき、MITライセンスである点がよい
    すぐに使う機会があるかは分からないが、かなり良さそうに見える。LaTeXらしい機能が必要な文章を書くが、提出先がLaTeXを強制していないなら、Notaを試してみると思う
    Knuthはほとんど半神のような存在だと思っているが、彼が天から降りてきてTeXを授け、「永遠に新しいものを試すな」と言ったわけではないのだから

    • TeXは確かに画期的だったが、時代の産物だと思う。今の基準ではばかげたメモリ制限に合わせるために、マクロ展開や組版手法にあまりに多くの巧妙さが注ぎ込まれていた
      現代的な言語が備えるミス防止の仕組みや便利機能もあまりに多く欠けている。LaTeXを使うときは、エスケープを1つ忘れて壊れるのを避けるため、ブロックを隔離する目的で\input{}の断片に大きく依存しなければならない
      現代的な再解釈をずっと望んでいるが、TeXに積み上がった数十年分の慣性とパッケージのせいで、抜け出しにくい局所最適に閉じ込められている感じがする
    • https://typst.app/も見てみる価値がある

  • 似たものとしては、https://pandoc.org/、https://quarto.org/、https://markdoc.dev/、https://mdxjs.com/、https://typst.app/がある

    • Pandocの対応形式一覧は印象的

  • この分野での新しい試みの問題は、既にあまりに混み合った場所に参入することだ。既存の解決策が完璧でないかどうかは、あまり重要ではない
    千年の建築史が積み重なったヨーロッパの歴史都市に入り、優れた新しい建物の設計を主張するようなもの。空き地は少なく、人々は新しいものを試すために古い構造物をただ取り壊したりはしない。圧倒的な利点を感じる必要がある
    建築では、鋼鉄と鉄筋コンクリートが垂直方向を開き、空間利用を大きく改善し、その後の歴史が変わった
    ASCII、reStructuredText、wikitext、Markdown、TeX/LaTeX、AsciiDoc、HTMLなどを「改善」すると称して、さらに別の文書形式へ人々を引き寄せるだけの未開拓の次元があるかどうかが核心
    よくある答えは、セマンティックなハイパーテキスト基盤。元々のビジョンはまだ実現されていない。今日の閉鎖型エコシステムがいずれ過ぎ去る悪夢だと仮定するなら、再び分散化されたWebには、現代的でユーザーフレンドリーで、力を与える文書作成基盤が必要
    ただし、文書作成と共有を新たな高みへ引き上げる別の次元もあり得る。革新の美しさは、既存のルールや知恵に縛られないところにある

    • 分散化Web、いわばUsenetに対応する「Userweb」を望むなら、BitTorrentのようなプロトコルが必要だと思う
      効率的な文書形式が必要で、そのためには何でもやろうとしない形式でなければならない。つまり表は標準的なスプレッドシート形式のように、文書タイプをファイルごとに分離すべきであり、表やグラフィックス（SVG）などを自前で全部やろうとするHTMLとは違うべき
      それぞれを別ファイルに分ければ、ユーザーはブラウザ1つですべてを見る代わりに、好みのプログラムを選んで文書を閲覧・操作でき、ネットワーク配信にも役立ち、ストレージや帯域幅が限られた環境でも有利になる
      だから私の見方では、新たに発明すべきものはない。既に発明されたものを専門化し、磨き込めばよい

  • リンクをたどってみると、https://willcrichton.net/nota/ は、Nota が意図している用途、つまりプログラミング言語の学術論文をより理解しやすくするというニッチでは、説得力のある利点を示している
    高品質な PDF としてレンダリングできるかどうかは、当然必要なことであり疑問でもある。既存システムとの互換性を考えると、LaTeX にレンダリングするほうが、もしかするとよいかもしれない

  • 基本的に Nota はマークアップ + コード（JavaScript）で、この組み合わせは MDX が狙っている領域でもある。以前にも誰かがこの点に触れたとき、作者は Nota はドキュメント向け、MDX は Web サイト向けだと言っていた: https://news.ycombinator.com/item?id=31349579
    だとすれば、Nota が広まるには誰かがプロダクトとして包み込む必要があると思う。成果物はよさそうに見えるが、ドキュメントを作るために Node.js を触るのは面倒すぎて、また LaTeX みたいな感じになる。大半の人は Notion やワープロを好むだろう

    • LaTeX、より一般には TeX 系は、消えたことがない。今でもほとんどの STEM 分野でジャーナル論文を書くための標準ツールだ
      さらに Nota は TeX 系の直接の競合ではない。Nota は Web ブラウザが読むものを作り、xxxTeX は PDF リーダーが読むものを作る。xxxTeX が他の出力形式も作れることは知っているが、たいていは PDF 生成に使われている
    • Nota にデフォルトスタイル、ある種の文章スタイルが含まれているという事実だけでも、MDX とはまったく別のレベルにある
      MDX は React/Vue など、どんなフレームワークとも使える準備ができているが、それは基本的に何の意見も提供しないという意味でもある
      Nota は静的サイトジェネレーターに差し込めそうに感じる。もちろん、そのためには両者が協調するようにしなければならないが、私より少し献身的な誰かにとっては実現可能な期待だと思う

  • テキストページを作るために JavaScript へコンパイルする言語がなぜ必要なのかわからない。同じ目的は AsciiDoc がこなしている
    O’Reilly のような実際の出版社も、書籍や Web サイトを作る入力形式として AsciiDoc を使っている

    • AsciiDoc には同意する。Markdown は比較的短いコンテンツに向いていて、LaTeX は引用・数式などを含む本格的な学術論文に近いとすれば、AsciiDoc はその間のちょうどよい位置をうまく突いている
      ここ数年 AsciiDoc を使ってきて、気に入っている。AsciiDoc がまだサポートされていない場所でだけ Markdown に戻っている。たとえば GitHub と GitLab は AsciiDoc のレンダリングをサポートしている
      PyPI は残念ながらまだ対応していないが、より多くの人が注目しているようでよい: https://github.com/pypa/readme_renderer/issues/205
    • Asciidoctor のおかげで asciidoc がいちばんよい。形式としてちょうどよいところを押さえているという点に同意する
      ただ、最近のツールにはもどかしさがある。Asciidoctor に多大な労力が注がれているのはわかるし感謝しているが、セマンティックな HTML5 出力がない、画像生成ツールとの統合が難しい、少なくとも必要以上に難しいし、自分のマシン全体で唯一の Ruby 依存関係というくらい重い
      Ruby の問題を除けば、こうした issue は GitHub で開かれているので、時間とリソースがさらに投入されれば解決されると思う

  • よくわからない。Emacs org-mode のほうがよく、JavaScript への依存も低そうに見える
    https://docusaurus.io/ も非常によく、柔軟だ。Nota を同じような形で拡張したいなら、この2つを見てみることを勧める

  • ほとんどが静的コンテンツで、必要ならインタラクティブなグラフや任意のカスタマイズを入れられるブログを、いちばん簡単に作る方法を考えていたところだ。Nota がよい選択肢なのか気になる
    他の選択肢として Quarto（https://quarto.org/）も見たし、Jekyll のようなシンプルな静的サイトブログを使って、必要なときに出力された HTML を直接編集することも可能かもしれない

    • 私は XHTML に少しカスタム XML を混ぜ、XSLT で最終的な XHTML を生成している: https://git.uberspace.net/homepage/
      こうすると HTML 全体を使え、生成プロセスをカスタマイズでき、依存関係も比較的管理しやすく、関連する形式も標準化されている
    • Astro を非常に強くおすすめする: https://astro.build/
      Astro は React スタイルのコンポーネントを書くと、実際に JavaScript が必要な場合を除いて純粋な HTML/CSSにコンパイルしてくれる。私の個人サイトとブログも Astro で作った: https://sjer.red/、ソースは https://github.com/shepherdjerred/shepherdjerred.com
      Astro でブログを作るチュートリアルもある: https://docs.astro.build/en/tutorial/0-introduction/
    • Hugo の shortcode を使う道もある。Jekyll にも似たものがありそうだし、Vega-Altair（Python）や plotly のようなデータ可視化ライブラリの出力 HTML ファイルを shortcode の入力として使える