HN 日本語サマリー

← 一覧へ戻る
その他

An architectural comparison of Obsidian Canvas and Heptabase

An architectural comparison of Obsidian Canvas and Heptabase (fluxlinks.com)

25 pointsby ezrasu8 コメント

要約

Obsidian CanvasとHeptabaseは、どちらも空間的なノート作成ツールですが、そのアーキテクチャは根本的に異なります。Obsidian Canvasは、個々の`.canvas`ファイル内にJSON Canvas形式で視覚的な配置を保存し、接続はファイル内に限定されます。一方、Heptabaseは、ホワイトボードをグローバルなカードライブラリに対するビューとして扱い、カード間の接続をワークスペース全体でインデックス化します。この違いは、データのポータビリティとワークスペース内のコンテキストの統合性に影響を与えます。

全文翻訳

Obsidian Canvas vs. Heptabase: ファイル中心とカード中心のアーキテクチャが空間的思考をどのように形成するか

一見すると、Obsidian Canvas vs. Heptabaseの議論は、2つの類似した空間的ノート作成ツールの選択のように見えます。どちらも無限の2Dキャンバスを提供し、ノートを並べて配置でき、アイデア間に矢印を描くことができます。

しかし、内部的には、それらのデータアーキテクチャは根本的に反対です。

短い答え: Obsidian Canvasは、オープンなJSON Canvas形式を使用して、個々の.canvasファイル内に視覚的な配置を保存します。Heptabaseでは、ホワイトボードは中央のカードライブラリに対する非所有ビューです。

実際には、これはObsidian Canvas上の線はノート間のリンクを作成しませんが、Heptabaseホワイトボード上の線は、両方のカードが記憶する接続を作成します。要するに、Obsidianの接続は外部ツール間でポータブルですが、ワークスペースのグラフ内ではインデックス化されていません。Heptabaseの接続はカード全体でインデックス化されていますが、その独自のシステムにロックされています。

長期的な知識ワークフローをObsidian Canvasで構築するか、Heptabaseのような専用の空間ツールに投資するかを決定しようとしている場合、UI機能を見ても答えは得られません。ファイル、カード、コンテキストをどのようにモデル化するかを見る必要があります。

アーキテクチャの分解: Obsidian Canvas vs. Heptabase

アーキテクチャ上の次元Obsidian CanvasHeptabase
ファーストクラスの市民ファイル (.mdノートおよび.canvasファイル)アトミックカード (ワークスペース全体でのグローバルエンティティ)
空間的組織オープンなJSON Canvasファイル内にMarkdownファイルまたはローカルテキストカードを埋め込むグローバルカードを複数のホワイトボードにわたるライブビューとしてマッピングする
接続線の意味ボードファイルに保存された視覚的な座標。ツール間でポータブルだが、ワークスペースグラフ内ではインデックス化されていないカード情報パネルに表示されるリレーショナル接続。ワークスペース内でインデックス化されているが、アプリにロックされている
コンテキスト認識キャンバスにバインド: コンテキストはキャンバスファイル内に存在し、ノート自体には存在しないコンテキスト認識: 各カードは、それが属するすべてのホワイトボードと接続されているすべてのカードを追跡する
ポータビリティ vs. インデックス化ポータブルだがインデックス化されていない: .canvasファイルはオープンなJSON Canvasを使用するが、ノートは接続を認識しないインデックス化されているが、プロプライエタリ: 接続はボード全体で累積されるが、オープンなインタラクティブグラフとしてエクスポートできない
最適な用途プロジェクトロードマップ、システムアーキテクチャ図、視覚的なブレインストーミングスケッチ空間的探索と線形記述を橋渡しする累積的な研究と長期的な思考

Obsidian Canvas: 単一ファイル内に保存された視覚レイヤー

Obsidianはローカルファースト哲学に基づいて構築されています。知識ベースはプレーンテキストMarkdownファイルのフォルダです。Obsidianはファイルをアトミックユニットとして選択しました。その選択が、ワークスペースをポータブルで耐久性のあるものにしています。そして、キャンバスが別のファイルにしかならず、接続を保存する場所がない理由でもあります。

1. 空間的組織: ファイルを単一キャンバスに埋め込む

Obsidian Canvasを作成すると、スタンドアロンの.canvasファイル（JSONとしてディスクに保存）が作成されます。

これにより、即座にアーキテクチャの分割が生じます。

  • キャンバス内に作成されたカードは、そのファイル内に留まります。キャンバス上で10個の簡単な思考カードを直接入力した場合、それらのカードはその.canvasファイル内にのみ存在します。それらを個別のMarkdownファイルに手動で1つずつ変換しない限り、ワークスペース内の独立したノートとして表示されません。
  • 外部ノートは埋め込みビューです。既存の.mdファイルをキャンバスにドラッグすると、Obsidianはそのファイルへの編集可能なビューポートをレンダリングします。ただし、キャンバスは外部からファイルのパスを参照しているだけです。

［画像: Obsidian CanvasがMarkdownファイルを視覚的なカードとして埋め込み、方向矢印付き］

2. アイデアの接続: 視覚的な線 vs. 実際のグラフリンク

空間ワークスペースでは、ノートを接続する線は、ノート自体と同じくらい意味を持つことがよくあります。

Obsidian Canvasでは、ボード上に描画された矢印は、特定の.canvasファイル内の視覚的な座標データとして保存されます。それらはMarkdownリンクや[[wikilinks]]として登録されず、Obsidianのグローバルグラフビューにも表示されません。キャンバス上のノートAからノートBへの矢印を描画した場合、コアリンクエンジンは2つのノート間のリンクを記録しません。

このアーキテクチャ上の制限は、ユーザーの間で頻繁に議論されるポイントです。Canvas Linksプラグインを紹介するObsidianコミュニティフォーラムのスレッドで、あるユーザーは次のように述べています。

“キャンバス内の視覚的な接続は実際のリンクではなく、グラフビューに表示されません。”

コミュニティプラグインは埋め込みをブリッジし、どのキャンバスがファイルを参照しているかを表示できますが、コアキャンバス線はリレーショナルグラフリンクではなく、ローカライズされた視覚データであり続けます。

3. コンテキスト認識: コンテキストはキャンバス内にあり、ノート内にはない

Obsidianのアーキテクチャは厳密にファイル中心であるため、Markdownファイルと.canvasファイルは構造的に分離されています。

Markdownファイルが複数のキャンバスにまたがって埋め込まれている場合、それは単に外部から表示されているだけです。ファイル自体は、その視覚的な配置に関するメタデータを一切保存しません。

  • 通常のエディタでノートを開いても、現在どのキャンバスがそれを埋め込んでいるかは表示されません。
  • キャンバス上の隣接するカードが何であるかはわかりません。
  • それに向けられた矢印ラベルや接続が何であるかはわかりません。

.canvasファイルから離れると、その空間コンテキストはキャンバスファイル内に残され、ノートは線形テキストの孤立した断片として残ります。

Obsidian Canvasの評価

Obsidian Canvasは、視覚的なブレインストーミング、プロセスフローチャート、システムマッピングに最適です。接続はキャンバスファイル内に留まるため、多くのボードにわたってリンクを蓄積する必要があるアトミックノートにはあまり適していません。

Heptabase: コンテキスト認識型思考ワークベンチ

Heptabaseは、反対のアーキテクチャ的観点から空間的ノート作成に取り組みます。ホワイトボードを独立したドキュメントを埋め込むコンテナファイルとして扱うのではなく、Heptabaseはノートが何であるかをノートがどこで表示されるかから分離します。

1. 空間的組織: ホワイトボードは非所有ビューとして

Heptabaseでは、システムの原子単位はファイルではなくカードです。

Heptabaseの公式ドキュメントでFundamental Elementsとして定義されているように：

“ホワイトボードはカードを所有しません。すべてのカードはカードライブラリに属します。同じカードを同時に複数のホワイトボードに配置できます。”

ホワイトボードは中央ライブラリに対する非所有ビューであるため、カードをホワイトボードに配置しても、それを分離したりネストしたりしません。コンテンツを複製したり同期を壊したりすることなく、まったく同じカードを同時に複数のホワイトボードに配置できます。1つのボードでカードに行われた更新は、そのカードが表示されるすべての場所に即座に反映されます。

［画像: Heptabaseホワイトボードがアトミックカードを視覚的なトピックに整理し、展開された線形カードエディタと並べて表示］

2. アイデアの接続: カード情報パネル内のホワイトボード接続

Heptabaseホワイトボード上の2つのカード間に接続線を描画すると、その関係はボード自体の外のワークスペースに直接反映されます。

  • カードAのカード情報パネルを開くと、接続されているカードの下にカードBが表示され、矢印が描画されたホワイトボードが示されます。
  • カードBのカード情報パネルを開くと、カードAからの着信接続が表示されます。
  • どちらかのカードの接続エントリをクリックすると、ホワイトボード上のその正確な空間座標に直接ジャンプします。

カードテキスト内のインライン@mentionが線形クロスリファレンスを処理する一方で、ホワイトボード線はカードがどこで開かれても追跡する専用の空間リンクレイヤーを提供します。

3. コンテンツアーキテクチャ: コンテキストを保持するカード

カードはグローバルエンティティであるため、ワークスペース全体にわたってリレーショナル履歴を保持します。

カードのカード情報パネルを開くと、その完全な空間コンテキストが表示されます。

  • 現在このカードが含まれているすべてのホワイトボード。
  • すべてのボードにわたって、これに接続されている、またはこれから接続されているすべてのカード。
  • 参照されているホワイトボード上のカードの正確な位置への直接ジャンプリンク。

ボード外でカードを開くと、その視覚的およびリレーショナルコンテキストにアクセスできます。

Heptabaseのアーキテクチャ上のトレードオフ: ポータビリティ vs. 統合

この深いコンテキスト統合には、明確な構造上のトレードオフがあります。それはデータポータビリティです。

Obsidian Canvasは、オープンなJSON Canvas仕様に準拠したスタンドアロン.canvasファイルとして空間配置を保存します。これは、外部スクリプトやサードパーティツールがボードを解析できることを意味します。

対照的に、Heptabaseは、カード、接続、ホワイトボード座標を独自のシステム内で管理します。Heptabaseはカードを標準Markdownファイルにエクスポートできますが、ホワイトボードは静止画像ファイルまたは線形カードリストとしてエクスポートされます。それらのカードを接続するインタラクティブな視覚的な線とリレーショナルグラフは、JSON Canvasのようなオープンな視覚形式にエクスポートできません。ファイル耐久性とベンダーニュートラルなポータビリティを、統合された空間ワークスペースと引き換えにしています。

Heptabaseの評価

Heptabaseは、視覚的な研究者向けの累積的な思考ワークベンチとしてうまく機能します。そのグローバルカードアーキテクチャにより、ホワイトボードで確立された関係は、時間の経過とともにワークスペース全体で累積されます。ただし、Heptabaseを採用するには、標準のプレーンテキストファイルに依存するのではなく、専用のプロプライエタリなエコシステムにコミットする必要があります。

2Dホワイトボードを超えて: 空間的ブレインストーミングが厳密な記述と出会うとき

Obsidian Canvas（個々のファイル内に保存された視覚レイヤー）とHeptabase（非所有ビューにマッピングされたグローバルカード）のアーキテクチャの違いを理解することで、各ツールが空間組織にどのようにアプローチするかを明確にします。

しかし、視覚的なマップよりも構造化された議論の作成を主な目標とする研究者や作家にとって、2Dホワイトボード自体は自然な限界に直面します。

  1. 2D矢印には明示的な論理的意味論がない: ホワイトボードでは、カードAとカードBの間の矢印は接続を示しますが、論理は示しません。それは、アイデアが主張を支持するか、仮定を否定するか、前提条件として機能するかを正式に指定しません。
  2. 2D空間から線形散文への翻訳の摩擦: ホワイトボードは空間座標にわたって思考を配置しますが、エッセイ、レポート、メモは順次読み取られます。広大な2Dキャンバスをまとまった原稿に変換するには、依然として空間配置を手動で線形段落に平坦化する必要があり、その背後にある論理骨格がしばしば失われます。
3番目のアプローチ: 明示的な命題ツリー

ホワイトボードは視覚的なブレインストーミングを最適化します。ドキュメントは順次読み取りを最適化します。散らばった探索と厳密な記述の間のギャップを橋渡しするには、2D座標ではなく、アイデア（主張、証拠、反論）の論理的依存関係をモデル化する必要があります。

［画像: FluxLinksが明示的な論理関係を持つ階層的な命題ツリーに議論を構造化］

この記事の議論を構造化するために使用されたインタラクティブな命題ツリーは、FluxLinksで探索できます。

要約: どのツールがあなたのワークフローに適していますか？

  • Obsidian Canvas を選択してください。ローカルファーストのデータ所有権、耐久性、標準Markdownファイルを優先し、図、コンセプトマップ、一時的なスクラッチパッド用の軽量な空間ボードが必要な場合。
  • Heptabase を選択してください。アトミックカード、PDFハイライト、空間接続がトピック全体にわたる永続的なリレーショナルネットワークに累積される視覚的な思考を必要とする研究を行っており、プロプライエタリなデータベーススキーマ内での作業を受け入れる場合。
  • FluxLinks を探索してください。複雑な研究を直接階層的な命題ツリーと構造化された散文に構造化することにより、2Dホワイトボードの平坦化の摩擦を回避したい場合。

よくある質問

HeptabaseのホワイトボードとカードをObsidianにエクスポートできますか？

Heptabaseカードのテキストコンテンツを標準Markdownファイルとしてエクスポートし、Obsidianワークスペースに直接インポートできます。ただし、ホワイトボードは静止画像または線形リストとしてエクスポートされます。それらのカードを接続するインタラクティブな視覚的な線と空間座標は、JSON Canvasのようなオープンな視覚形式にエクスポートできないため、空間リレーショナルグラフはツール間でシームレスに移行できません。

Obsidian Canvasの接続線はグラフビューのバックリンクとしてカウントされますか？

いいえ。Obsidian Canvas上に描画された接続線と矢印は、個々の.canvasファイル内のレイアウトデータとして厳密に保存されます。それらは接続されたMarkdownノートに[[wikilinks]]を書き込まず、Obsidianのグローバルグラフビューやバックリンクパネルにも表示されません。

はいといいえ。同じ.mdノートファイルを複数の.canvasファイルに埋め込むことができ、そのノートに対して行われたテキスト編集は同期されたままになります。ただし、各キャンバス上の接続、隣接するカード、矢印ラベルは、それぞれの.canvasファイルに限定されたままです。個々のノートは、どのキャンバスがそれを埋め込んでいるか、またはそれがどのように接続されているかについて、ネイティブな認識を持っていません。

Heptabaseと比較して、Obsidian Canvasは完全にオフラインでローカルファーストですか？

はい。Obsidian Canvasは、ユーザーアカウントやネットワーク接続を必要とせずに、ローカルのプレーンテキストとローカルJSONファイルで完全に動作します。Heptabaseはクライアントサイドのオフライン編集をサポートしていますが、その統合カードライブラリとクロスデバイス同期は、プロプライエタリなクラウドデータベースアーキテクチャを中心に構築されています。

*開示: 私はFluxLinksを開発しています。ObsidianもHeptabaseもこの投稿を後援していません。