From 405f287e1bb3700ca074a392f621a69d7347ac70 Mon Sep 17 00:00:00 2001 From: Yury Bondarenko Date: Thu, 26 Jun 2025 13:04:26 +0200 Subject: [PATCH] Explain metadata registry requirement for PATCH paths --- metadata-patch.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/metadata-patch.md b/metadata-patch.md index 19e65cbb..d698e770 100644 --- a/metadata-patch.md +++ b/metadata-patch.md @@ -35,6 +35,13 @@ The examples in each section below build on each other, assuming an initial meta } ``` +PATCH operations targeting metadata must specify a JSON `path` relative to the DSpace object, valid for the following levels: +- All metadata: `/metadata` → `value` must be an object (if applicable) +- All values of one metadata field: `/metadata/dc.title` → `value` must be an array (if applicable) +- One values of one metadata field: `/metadata/dc.title/0` → `value` must be an object (if applicable) + +Any metadata field explicitly included in the `path` must be part the metadata registry. PATCH requests targeting unknown metadata fields will fail with HTTP 422 (unprocessable entity). + Note: The metadata of items _in submission_ is modeled in the same way described here -- as a map of metadata keys to an ordered array of values. The primary difference is where the metadata is located within the JSON representation. The documentation and examples below apply to archived