象手露
- コレクション／サブコレクションは仮想フォルダ。リンクを構造化しているだけで、実体には影響しない。
- タグは階層化できない。もし、Obsidianのような階層化タグをサポートすると、タグ階層とコレクション階層の区別が困難だろう。つうか、同じになってしまいそう。
- 物理的な意味でのフォルダ〈ディレクトリ〉は使わないようだ。storageディレクトリの配下に、独自のIDを振ったサブディレクトリがあり、それがライブラリのアイテムの実体になる。
- 管理対象データと、他デバイスと“共有されるファイル”は別な概念かも知れない。
- PDFアノテーションは、PDFのチャンク（スタート位置アドレスとレンジ・オフセット）に対してアウトオブラインの情報を紐づける。アウトオブラインなので、本体PDFは無変更。
- Zotero拡張機能は、xpiファイルで共有・交換する方式。
- Mendeleyだと、既読未読管理ができるようだが、見当たらない。
- アノテーションメモはMarkdownで書ける。
- PDFへのハイライト指定〈リージョン、チャンク〉とスポットまたはリージョンへのアノテーションは出来るようだ。
検索〈サーチ〉に関しては、あるロールのセクション／ブロック内に指定したタームが出現するか？ で検索できるのは便利だと思う。が、ロール名やセクション属性名や出現するタームの標準化がされてないと、曖昧性は避けられない。トライアンドエラー検索になるだろう。
メディアファイルに対するアノテーションノートは、Obsidianノートのような形式でも書けるが、紐づけ先のスポット／リージョンのメディファイル内アドレッシングが厳しいかも知れない。
論文リソースの集まりはだいたい「ライブラリ」と呼ぶようだ。
別なアプリケーションであるpapersでは検索式を仮想フォルダのように扱える。名前付きの検索式による“ビュー”の発想だだが、UIの作り方によってはけっこう便利だろう。検索抽出により、図だけを集めるとかができる。再編成機能と言える。
毎度のことながら、「アイテム」「ライブラリ」「エントリー」「レコード」「コレクション」「リスト」などの言葉が、アプリケーションのあいだで同じだったり微妙に違っていたり。
二値のトグル（ブール値だが）は「フラグ」と言ったりする。複数のフラグは色で区別する。レーティングも、有限個の数値に過ぎないが、人間がレーティングだと解釈すればレーティング。
ディスカバリー機能やレコメンド機能も重要になるが、これはなんらかの関連性情報がないとできない。結局は、検索機能／マッチング機能ということになる。
インターネット上のメンション〈言及〉の集約、インターネット上のサイテーション／リファレンスの集約。集約計算でメトリクスを計算できる。
データベースのビューと同じ意味でのビュー（読み取り専用）を定義して、ペインとして配置できたら面白いかも。ペインとは、同じドキュメントに対する異なるビューを表示する視覚的な場所。スクロールなどが連動することを想定。
