JSON-Schema validators for signature commons entities. Designed to allow one to flexibly validate arbitrary metadata in the signature commons database.
npm install --save @dcic/signature-commons-schema
import { validate } from '@dcic/signature-commons-schema'
validate({your_object})
(
# Parse and put json on single line
jq -c '.' << EOF
{
"your": "json"
}
EOF
# Run it through the validator (with verbose debugging; otherwise omit DEBUG)
) | DEBUG=signature-commons-schema signature-commons-schema your_validator
# stdout -- the valid json(s)
# stderr -- any errors
# exit code -- the number of errors
s
core/
: Fundamental schemas which define how the schemas should even be usedmeta.json
: JSON-LD style constraintslibrary.json
,signature.json
,entity.json
: Primary signature common primitives, they exposemeta
as an instance ofmeta.json
examples.json
: Schema example tests structure
meta/
: Meta schemas designed for the respective primary signature common primitive meta fields.src
: Validator built with https://github.com/epoberezkin/ajv
At the most basic level, a given instance should reference the validation context which it implements.
Given an abstract concept, we can write a validator for it:
{
"$id": "myimportantconcept.json",
"$schema": "http://json-schema.org/draft-04/schema#",
"description": "My important concept",
"allOf": [
{
"$ref": "core/meta.json"
},
{
"type": "object",
"properties": {
"my_important_field": {
"type": "string",
"description": "My important description"
}
},
"required": [
"my_important_field"
]
}
]
}
Meta here enforces the constraint of the $validator
definition, which references the abstract validation. Now we can write any number of instances for our concept.
{
"$validator": "myimportantconcept.json",
"my_important_field": "my_important_value"
}
We can validate that this is true by grabbing the $validator
file and validating the json itself.
import {validate} from '@dcic/signature-commons-schema/validate'
validate(data)
The $validator
here is therefore doubling as semantic meaning, as described in the descriptions, and computational validation. Better yet, this allows us to support self-described objects, which is how we can deal with arbitrary metadata.
{
"$validator": "core/signature.json",
"meta": {
"$validator": "meta/signature/gene.json",
...all the gene signature relevant metadata
},
"values": {
"entity": "id",
"value": "val"
}
}
meta/signature/gene.json
then is capable of defining the specifics of the metadata implementation, potentially as a subset of other metadata.
{
"$id": "meta/signature/gene.json",
"allOf": [
{
"$ref": "meta/signature/common.json"
},
{
"type": "object",
"properties": {
...gene specific signature properties
}
}
]
}
This repository has examples and tests which should be re-used to validate that APIs and Databases as part of the signature commons are serving and consuming data which follows this same approach. The actual schemas can be stored and referenced from this repository as they are public, persistent, and versioned.