{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://bibframe-json.org/v0.1/schema/bounded.json",
  "title": "A Concise Bounded Description",
  "description": "An Instance with its Work embedded, and with the resources they name described in place: enough in one document to explain the Instance without fetching anything.",
  "$comment": "cbd-01.md is LC's description of how they serialize a BOUNDED, and it describes RDF/XML: all principal resources as siblings under one rdf:RDF, linked by rdf:resource. That arrangement suits XML, where there is no natural root, and Marva reads it.\n\nJSON has a natural root, and LC never specified the JSON-LD -- their .bounded.jsonld is a flat array of expanded nodes, and Blue Core's was the same. So this takes the other option: the document is the Instance, and everything else is described where it is referenced. Measured over 59 CBDs from a running system it is 11% smaller than the sibling arrangement and describes exactly the same resources, and it puts a related Work where it belongs -- under the relation that reaches it -- rather than leaving a reader to rejoin URIs.\n\nThe one structural claim, and the thing that tells a bounded description from a linked one: bf:instanceOf embeds the Work. A linked description holds a bare URI there, because the Work is a resource of its own. The back-reference from the embedded Work is still bare, which is how a JSON-LD processor breaks the cycle and is what linked.json already permits.\n\nEverything else is linked.json, referenced rather than copied so the definitions exist in one place.",
  "allOf": [
    {
      "$ref": "linked.json"
    },
    {
      "$ref": "#/$defs/instance-at-the-root"
    },
    {
      "$ref": "#/$defs/work-embedded"
    }
  ],
  "$defs": {
    "instance-at-the-root": {
      "title": "The document is an Instance",
      "description": "A bounded description covers one Instance. Blue Core serves one for an Instance and nothing else; a Hub is described by the 'decomposed' form, which is a different document.",
      "type": "object",
      "required": [
        "@id",
        "@type"
      ],
      "properties": {
        "@type": {
          "anyOf": [
            {
              "type": "array",
              "contains": {
                "const": "Instance"
              }
            },
            {
              "const": "Instance"
            }
          ]
        }
      }
    },
    "work-embedded": {
      "title": "With its Work embedded",
      "description": "Not a bare URI, which is what a linked description holds. This is the difference between the two, and the reason a bounded description explains itself.",
      "type": "object",
      "required": [
        "instanceOf"
      ],
      "properties": {
        "instanceOf": {
          "type": "array",
          "minItems": 1,
          "items": {
            "allOf": [
              {
                "$ref": "linked.json#/$defs/Work"
              },
              {
                "type": "object",
                "required": [
                  "@id",
                  "@type"
                ],
                "properties": {
                  "@type": {
                    "anyOf": [
                      {
                        "type": "array",
                        "contains": {
                          "const": "Work"
                        }
                      },
                      {
                        "const": "Work"
                      }
                    ]
                  }
                }
              }
            ]
          }
        }
      },
      "$comment": "The embedded Work is checked against the Work definition, not merely as a reference. Without that it is only checked as a reference -- which is open, so a blank node keeping its @id inside the Work would pass. The sibling arrangement got this for free, because every member was dispatched as a resource; nesting has to ask for it.\n\nAgainst #/$defs/Work rather than against linked.json, which is the whole document schema and now requires @context. An embedded Work is a Work, not a document, and must not be made to carry a context of its own. The definition carries the same shared rules either way: each split file holds them itself, which tests/test_split_schema.py checks."
    }
  }
}