JSON Schema — linkml documentation

# JSON Schema

## Example Output

personinfo.schema.json

## Overview

JSON Schema is a schema language for JSON documents.

JSON-Schema can be generated from a LinkML schema and used to validate JSON documents using standard JSON-Schema validators.

To run:

    gen-json-schema personinfo.yaml > personinfo.schema.json

To use this in combination with the standard python jsonschema validator (bundled with linkml):

    jsonschema -i data/example_personinfo_data.yaml personinfo.schema.json

See also

Data Validation for other validation strategies

Note

Note that any JSON that conforms to the derived JSON Schema can be converted to RDF using the derived JSON-LD context.

### Inheritance

Because JSON-Schema does not support inheritance hierarchy, slots are “rolled down” from parent.

For example, in the personinfo schema, slots such as id and name are inherited from NamedThing, and aliases are inherited from a mixin:

    NamedThing:
      slots:
        - id
        - name

    HasAliases:
      mixin: true
      attributes:
        aliases:
          multivalued: true

    Person:
      is_a: NamedThing
      mixins:
        - HasAliases
      slots:
        - birth_date
        - age_in_years
        - gender

(some parts truncated for brevity)

This would generate the following JSON-Schema:

    "Person": {
       "additionalProperties": false,
       "description": "A person (alive, dead, undead, or fictional).",
       "properties": {
          "age_in_years": {
             "type": "integer"
          },
          "aliases": {
             "items": {
                "type": "string"
             },
             "type": "array"
          },
          "birth_date": {
             "type": "string"
          },
          "gender": {
             "$ref": "#/definitions/GenderType"
          },
          "id": {
             "type": "string"
          },
          "name": {
             "type": "string"
          },
       },
       "required": [
          "id"
       ],
       "title": "Person",
       "type": "object"
    },

### Composition

JSON-Schema support schema composition through:

- allOf

- anyOf

- oneOf

- not

See Schema Composition

Currently there are no directly equivalent constructs in LinkML, although future versions of LinkML will support an expressive constraint mechanism.

Note that many uses of the above constructs may be better handled by using inheritance (see below) in LinkML. Future versions of LinkML may support translation of certain object oriented patterns to JSON-Schema compositions, for example:

- The union_of slot could be used to generate oneOf

### Inlining

LinkML separates the underlying logical model from choices of how references are inlined in JSON.

If an inlined directive is added to a slot definition as follows:

    has_employment_history:
      range: EmploymentEvent
      multivalued: true
      inlined: true
      inlined_as_list: true

then the JSON-Schema will use a `$ref`:

    "has_employment_history": {
       "items": {
          "$ref": "#/definitions/EmploymentEvent"
       },
       "type": "array"
    },

However, if a slot is not inlined and the range is a class with an identifier, then the reference is by key.

For example, given:

    FamilialRelationship:
      is_a: Relationship
      slot_usage:
        related to:
          range: Person
          required: true

Here the value of `related_to` is expected to be a string must be an identifier for a `Person` object:

the range is treated as a simple string in the JSON-Schema

    "FamilialRelationship": {
       "additionalProperties": false,
       "description": "",
       "properties": {
          "ended_at_time": {
             "format": "date",
             "type": "string"
          },
          "related_to": {
             "type": "string"
          },
          "started_at_time": {
             "format": "date",
             "type": "string"
          }
       },
       "required": [
          "type",
          "related_to"
       ],
       "title": "FamilialRelationship",
       "type": "object"
    },

Thus the JSON-Schema loses some information that is useful for validation, and for understanding of the schema.

LinkML also supports the ability to inline multivalued slots as dictionaries, where the key is the object identifier. See Inlining

This example schema supports inlining a list of people as a dictionary:

    classes:
      Container:
        tree_root: true
        attributes:
          persons:
            range: Person
            inlined: true
            multivalued: true
      Person:
        attributes:
          name:
            identifier: true
          age:
            range: integer
            required: true
          gender:
            range: string
            required: true

The following data is conformant according to LinkML semantics:

    {
     "persons":
       {
         "Bob": {
             "age": 42,
             "gender": "male"
         },
         "Alice": {
             "age": 37,
             "gender": "female"
         }
       }
    }

This presents an additional complication when generating JSON-Schema: semantically the `name` field is required (all identifiers are automatically required in json-schema). However, we don’t want it to be required in the body of the dictionary since it is already present as a key.

The JSON-Schema generator takes care of this for you by making an alternative “laxer” version of the Person class that is used for validating the body of the `persons` dict.

This is what the underlying JSON-Schema looks like:

    "$defs": {
       "Person": {
          "additionalProperties": false,
          "description": "",
          "properties": {
             "age": {
                "type": "integer"
             },
             "gender": {
                "type": "string"
             },
             "name": {
                "type": "string"
             }
          },
          "required": [
             "name",
             "age",
             "gender"
          ],
          "title": "Person",
          "type": "object"
       },
       "Person__identifier_optional": {
          "additionalProperties": false,
          "description": "",
          "properties": {
             "age": {
                "type": "integer"
             },
             "gender": {
                "type": "string"
             },
             "name": {
                "type": "string"
             }
          },
          "required": [
             "age",
             "gender"
          ],
          "title": "Person",
          "type": "object"
       }
    },
    "$id": "http://example.org",
    "$schema": "http://json-schema.org/draft-07/schema#",
    "additionalProperties": false,
    "properties": {
       "persons": {
          "additionalProperties": {
             "$ref": "#/$defs/Person__identifier_optional"
          }
       }
    },
    "title": "example.org",
    "type": "object"

### Patterns

Both LinkML and JSON-Schema support the same subset of ECMA-262 regular expressions.

See Regular Expressions.

For example, the following schema fragment

    classes:
      # ...
      Person:
        # ...
        slot_usage:
          primary_email:

will generate:

    "primary_email": {
       "pattern": "^\\S+@[\\S+\\.]+\\S+",
       "type": "string"
    }

### Enums

Enumerations are treated as simple strings. If the LinkML schema has additional metadata about the enumeration values, this is lost in translations.

Example:

    classes:
      # ...
      FamilialRelationship:
        is_a: Relationship
        slot_usage:
          type:
            range: FamilialRelationshipType
            required: true
          related to:
            range: Person
            required: true
      #...

    enums:
      FamilialRelationshipType:
        permissible_values:
          SIBLING_OF:
            description: a relationship between two individuals who share a parent
          PARENT_OF:
            description: a relationship between a parent (biological or non-biological) and their child
          CHILD_OF:
            description: inverse of the PARENT_OF type

Generates

    "FamilialRelationship": {
       "additionalProperties": false,
       "description": "",
       "properties": {
          "ended_at_time": {
             "format": "date",
             "type": "string"
          },
          "related_to": {
             "type": "string"
          },
          "started_at_time": {
             "format": "date",
             "type": "string"
          },
          "type": {
             "$ref": "#/definitions/FamilialRelationshipType"
          }
       },
       "required": [
          "type",
          "related_to"
       ],
       "title": "FamilialRelationship",
       "type": "object"
    },
    "FamilialRelationshipType": {
       "description": "",
       "enum": [
          "SIBLING_OF",
          "PARENT_OF",
          "CHILD_OF"
       ],
       "title": "FamilialRelationshipType",
       "type": "string"
    },

## Docs

### Command Line

### Code