Markdownで文献出典を扱う実用的な方法

Share

Markdownで文章を書いていると、学術的な小論や技術記事など、ある程度の正確さを求められる文書で文献出典をどう扱うかという問題に直面する。Markdownの仕様には脚注や参考文献を管理する標準的な仕組みがなく、エディタごとの独自拡張に頼ると将来の移行時に困る。本稿では、プレーンテキストとしての可搬性を保ちながら文献出典を扱う方法を比較し、実用的な選択肢を検討する。

前提と要件

文献出典の記法に求められる性質は以下の通りである。

  • 可搬性: 特定のエディタやプラットフォームに依存しない。プレーンテキストとして意味が通じる
  • 執筆時の効率: 書いている途中で文献リストとの間を行き来する必要がない
  • 可読性: 出典の挿入が本文の読みやすさを大きく損なわない
  • 検索性: 後から特定の文献を参照している箇所を検索できる
  • 自己完結性: リンクや外部参照に依存せず、テキスト単体で出典情報が完結する

リンクベースの参照([[]] やハイパーリンク)は、リンク先が移動・消失すると出典情報そのものが失われるため、長期的な文書管理には不向きである。

主な方法の比較

インライン括弧方式(著者年スタイル)

本文中に著者名と出版年を括弧で挿入する方法である。APAやシカゴスタイルなどの学術引用規格に準拠しており、最も広く認知されている。

認知負荷理論によれば (Sweller 1988)、作業記憶の容量は限られている。

本文の流れを大きく妨げず、どの出典に基づく記述かが明確になる。ただし、括弧内の情報だけでは論文タイトルが分からないため、末尾に参考文献リストを別途用意する必要がある。

段落末尾集約方式

段落全体の出典を末尾にまとめて記載する方法である。

認知負荷理論によれば、作業記憶の容量は限られている。より近年の研究ではこの理論が実証されている。
[Sweller 1988; Kirschner et al. 2006; Clark 2010]

本文中に括弧が現れないため読みやすいが、どの記述がどの出典に対応するかが曖昧になるという欠点がある。厳密な引用が求められる場面には不向きである。

セクション末尾方式

セクションの末尾に出典をまとめる方法である。段落末尾集約方式をさらに粗い粒度にしたものといえる。カジュアルな技術記事やメモには適しているが、学術的な正確さは期待できない。

インライン完全記載方式

出典情報を括弧内にすべて書き込む方法である。

認知負荷理論によれば (Sweller, J. (1988). Cognitive load during problem solving. Cognitive Science, 12(1), 257-285)、作業記憶の容量は限られている。

自己完結性は最も高いが、本文の可読性を著しく損なう。

実用的な妥協案

上記の方法を踏まえると、実用上はインライン括弧方式を拡張し、著者年に加えて論文タイトルの一部も括弧内に含める方法がバランスがよい。

認知負荷理論によれば (Sweller 1988: Cognitive Load Theory)、作業記憶の容量は限られている。

この方法には以下の利点がある。

  • 著者年だけの場合と異なり、括弧内を見るだけで何の文献かが分かる
  • 完全記載方式ほど冗長にならず、本文の可読性を保てる
  • 執筆中に参考文献リストを参照する必要がない
  • プレーンテキストとして自己完結しており、エディタを問わず意味が通じる
  • 正式な参考文献リストが必要な場合は、末尾に追加すればよい

詳しさの度合いは文書の性質に応じて調整すればよい。個人的なメモであれば著者年のみで十分であり、公開する文書であればタイトルを含めた方が読者に親切である。いずれにしても、プレーンテキストの可搬性を維持するという原則に従えば、特定のツールやプラットフォームに縛られずに文献出典を扱うことができる。

Read more

青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu

イケイケなWinスクショアプリを作りました

パソコンのスクショってなんというか、地味というか、撮ってそのままだと何とものっぺりしていますよね。 特にWindowsだとMacっぽい丸っこい感じとかもなく、無骨だなあと。 ということで、それっぽくおしゃれな背景や角丸を付けておしゃれに撮影をしてくれるスクショアプリを作りました。 GitHubで公開しています。 GitHub - P4suta/Snaply: Snaply — a modern, clean-architecture Windows screenshot tool (WinUI 3 / .NET 10)Snaply — a modern, clean-architecture Windows screenshot tool (WinUI 3 / .NET 10) - P4suta/SnaplyGitHubP4suta ウィンドウ・領域選択・スクリーンのキャプチャができます。 タッチスクリーンなどにも対応しているはずです。 撮影をすると、クリップボードにコピーされ、フォルダーへの保存もされます。

By Sakashita Yasunobu
Find My Files

Find My Files

Windowsにおける爆速ファイル検索アプリの定番といえば、Everythingです。 voidtoolswebhost2 その高速さの理由は、NTFSの仕組みをうまく活用していることにあります。Windowsで一般的に使われているNTFSには、ファイル情報を管理するマスターファイルテーブル(MFT)と、ファイルシステムの変更履歴を記録するUSN Journalがあります。Everythingはこれらを利用することで、初回に高速にファイル一覧を構築し、その後はUSN Journalを監視してリアルタイムにインデックスを更新しています。そのため、数百万ファイル規模の環境でも非常に高速な検索を実現しています。 もちろん、単純にファイル名やパスを保持するだけでは、大量のメモリを消費してしまいます。また、数百万件ものファイルから一瞬で目的のものを見つけるためには、メモリ効率の高いデータ構造や高速な検索アルゴリズムなど、さまざまな工夫が必要になります。 このように、Everythingは見た目こそシンプルですが、中身はかなり高度なことをやっているソフトウェアです。 なお、Everyth

By Sakashita Yasunobu