fix: clarify objects that represent collections

2-core-model.md

@@ -10,7 +10,7 @@ Worldspaceは、Clientが探索できる**ObjectのTree**として公開され
 
 WIPではObjectとエントリを別の構造として定義しない。**ObjectをWorldspaceのTree上の位置として扱うとき、そのObjectをエントリと呼ぶ。**
 
-したがって、ObjectはTree上で親子関係を持ち得るし、途中のNodeもそのまま操作対象になってよい。例えば`articles`はCollection Objectとして、そのInterfaceに`query`等を宣言し、配下に個別Articleを配置できる。
+したがって、ObjectはTree上で親子関係を持ち得るし、途中のNodeもそのまま操作対象になってよい。例えば`articles`は対象の集合を扱うObjectとして、そのInterfaceに`query`等を宣言し、配下に個別Articleを配置できる。
 
 ## ClientとHost
 

2.1-object-tree-schema.md

@@ -167,7 +167,7 @@ Tree上のchildrenとして自然に列挙できるのは、**indexableなObject
 - 比較的安価に取得できる。
 - 所有または内包関係として自然に理解できる。
 
-全件列挙が高コストまたは不自然な集合は、Treeへ直接展開しない。Collection ObjectのOperationを使って検索、filter、paginationを行い、resultとして関連する`entry`を返す。
+全件列挙が高コストまたは不自然な集合は、Treeへ直接展開しない。対象の集合を扱うObjectのOperationを使って検索、filter、paginationを行い、resultとして関連する`entry`を返す。
 
 例えば、大規模なIssue collectionは次のように公開できる。
 

4-client.md

@@ -83,7 +83,7 @@ Clientは`observe(path, depth)`を使い、対象Objectだけが必要なら`dep
 
 Response nodeの`children`が省略されている場合、そのnodeのchildrenは未観測であり、空であるとは扱わない。`children`が存在する場合、その一覧は完全であり、空arrayならindexable childが存在しない。Clientは起点pathと各Objectの`name`からchild pathを導出する。`children`が存在するnodeをcacheへmergeするときは、そのEntryで観測済みのdirect child edgeをresponseの完全な一覧で置き換える。`children`が省略されたnodeは構造について新しい情報を持たないため、既存edgeを削除したり、観測済みの一覧を未観測へ戻したりしない。
 
-件数の非常に多いCollectionの個々の要素は、通常indexableな子エントリとして露出しない。個別要素はCollection Objectの`query`や`list`等のOperationを通して発見することを想定する。
+件数の非常に多い集合の個々の要素は、通常indexableな子エントリとして露出しない。個別要素は対象の集合を扱うObjectの`query`や`list`等のOperationを通して発見することを想定する。
 
 ## Interestと取得計画
 

draft/filesystem-discovery.md

@@ -10,7 +10,7 @@ Indexableな範囲の全量取得をClientで縮めるのではなく、Hostが
 
 ## なぜFS全体をindexableにしないか
 
-Indexable childrenには、件数がboundedまたは現実的な範囲で列挙でき、比較的安価で、自然な所有・内包関係であることが求められる。全件列挙が高コストまたは不自然な集合は、Collection Operationで検索・filter・paginationし、`entry` を返すのが既存の方針である。
+Indexable childrenには、件数がboundedまたは現実的な範囲で列挙でき、比較的安価で、自然な所有・内包関係であることが求められる。全件列挙が高コストまたは不自然な集合は、対象の集合を扱うObjectのOperationで検索・filter・paginationし、`entry` を返すのが既存の方針である。
 
 任意のfilesystem directoryは、浅い位置に大量のfileやdirectoryを持ち得る。Depthが小さくてもAIが把握できない件数になるため、depth制限だけでは適切な探索空間を作れない。