Expansion drops Annotations that carry multiple bodies
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- javascript
調査の方向性
controllers/crud.js と assertionsFrom() から始め、次に controllers/gog.js の expand()、findLeafAnnotationsFor()、および Annotations-Merged レスポンスの処理を調べてください。配列のボディと複数キーを持つオブジェクトのボディをどのように扱うべきかを解決し、展開とマージ数が一致することを確認してください。payload にはテストパスが記載されていないため、完了時には説明された動作のカバレッジを含めてください。
索引モデルが issue の本文から書いたものです。
説明
Split out of the static review of #286 so it does not block that PR.
What happens now
assertionsFrom() in controllers/crud.js returns early on an Array body:
if (!body || typeof body !== "object" || Array.isArray(body)) return assertions
An Annotation carrying multiple bodies is still gathered by findLeafAnnotationsFor() and still counted in the Annotations-Merged response header, but contributes nothing to the expanded entity. From the client's side that reads as a nonzero merge count with no merged data.
expand() in controllers/gog.js now skips them explicitly too (added in #286 — previously a one element Array body merged onto the entity under the key "0").
Why it matters
The W3C model explicitly allows multiple bodies, and each element is usually an ordinary single-key assertion rather than a structural construct. Real examples already in annotationStore.alpha:
[{"contributor":{"label":"Dunbar, Paul Laurence","id":"http://viaf.org/viaf/76335432"}},
{"issued":"1895-04-17"},
{"identifier":"Box 1, F1"},
{"uri":"https://udspace.udel.edu/handle/..."}]
Current impact: none
Measured against production at the time of the #286 review:
- 911 leaf Annotations have an Array
body - 0 of them target a
rerum.io/v1/id/URI under any of the six keys inTARGET_KEYS
Since /v1/id/:_id/expanded only expands RERUM-stored entities, nothing reachable through the endpoint is affected today. This is a gap that surfaces the first time an app writes a multi-body Annotation onto a RERUM entity.
Possible approach
Each element is typically itself a single assertion, so the existing logic handles them if it recurses:
if (Array.isArray(body)) {
for (const one of body) assertions.push(...assertionsFrom({ body: one }))
return assertions
}
Worth deciding at the same time:
- whether
Annotations-Mergedshould count Annotations gathered or Annotations that actually contributed an assertion - whether
controllers/gog.jsexpand()should follow, or stay on single-body-only for its DEER-shapedvalueObjectwrapping
Related
Multi-key object bodies (not Arrays) are also dropped whole rather than partially, by the keys.length !== 1 check. Only 1 such document exists in production, so it was not worth acting on separately, but it is the same design question.
Reference
- W3C Web Annotation Data Model, multiple bodies: https://www.w3.org/TR/annotation-model/#multiple-bodies
- 主要言語
- JavaScript
- スター
- 3
- フォーク
- 6
- 平均マージ
- 4日 9時間
- マージ済み PR（30日）
- 5
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
CenterForDigitalHumanities/rerum_server_nodejs のほかの issue
-
bug documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
backend dependencies easy
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
CenterForDigitalHumanities/rerum_server_nodejs#290 · コメント 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 50/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 74/100
CenterForDigitalHumanities/rerum_server_nodejs の issue をすべて見る
似ている issue
-
bug CI breakage triage needed
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
oppia/oppia#27517 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
draftomen enhancement size: S
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
andreagrandi/draftomen#761 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
HarperFast/harper#2866 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
HarperFast/harper-pro#927 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
anthropics/skills#1897 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信