From 126e038ee2f0eb1a0b4709cfd3706b21d52ff02b Mon Sep 17 00:00:00 2001 From: Hare Date: Wed, 7 Oct 2026 03:55:44 +0900 Subject: [PATCH] fix: clarify objects that represent collections --- 2-core-model.md | 2 +- 2.1-object-tree-schema.md | 2 +- 4-client.md | 2 +- draft/filesystem-discovery.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/2-core-model.md b/2-core-model.md index d699c2f..340b7e7 100644 --- a/2-core-model.md +++ b/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 diff --git a/2.1-object-tree-schema.md b/2.1-object-tree-schema.md index 3eab34b..9029e95 100644 --- a/2.1-object-tree-schema.md +++ b/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は次のように公開できる。 diff --git a/4-client.md b/4-client.md index f0cc1d2..7756a65 100644 --- a/4-client.md +++ b/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と取得計画 diff --git a/draft/filesystem-discovery.md b/draft/filesystem-discovery.md index 4782e84..3e42686 100644 --- a/draft/filesystem-discovery.md +++ b/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制限だけでは適切な探索空間を作れない。