maayanlab/signature-commons-schema

JSON-Schema validators for signature commons entities

signature-commons-schema's Issues

Decide between `@context` / `@context+@type` / `$schema`

I've started to adopt $schema given that Loopback seems to be using that style syntax. It's possible we adopt a hybrid of the two but it needs to be formalized.

• Visual Studio Code supports automatic recognition of $schema, which it utilizes to lint and provide autocompletion for the json which specifies it.
• According to JSON Schema's docs, $schema should not appear in sub-schemas.
• We'll soon need to determine a key-type for #5 (potentially $validator)
• JSON-LD @context / @type is meant to provide semantic meaning, there is no enforcement

Integrate UI-Schema; essential display related information

Some information is more relevant for the purposes of display than others--that information should be identified in the schema and utilized in the UI for determining what gets shown (first) and what gets hidden in details.

We'll need to come up with a scheme which makes it possible to add this information to our schemas.

Some information can be directly linked to other places by URI--this is related to JSON-LD and RDF-style metadata which can and should be added both in the schema and the instance.

Formalize helper-assisted validation specification

As hinted in our tests: https://github.com/dcic/signature-commons-metadata-api/blob/master/test/acceptance/util/test-validate.ts#L47-L62
We need to create a way of getting validate to load an external script for validation.

Where standard schema validation works like this

validate({
  $schema: 'url_to_schema_used_for_validation',
  ...obj_instance
}) == ZSchema(obj, await fetch(obj.$schema))

Validator validation could work like this

validate({
  $validator: 'url_to_module_used_for_validation',
  ...actual schema instance
}) == (await import(obj.$validator))(obj)

In other words, the default $validator could just be zschema:

export default function default_validator(obj) {
  return ZSchema(obj, await fetch(obj.$schema))
}

And validate simplifies to

export default function validate(obj) {
  assertType<JSONLD>(obj)
  if(obj.$validator === undefined)
    obj.$validator = 'path_to_default_validator'
  return (await import(obj.$validator))(obj)
}

The adopted $data proposal paired with other features implemented in ajv make it an attractive target for implementing schema validation with.

Enable the concept of Collections/Dataset--a level above Libraries

A collection is a set of libraries, e.g. Enrichr, CREEDS

Also relevant for the data API

Fully integrate with openapi / typescript for tab completion and type safety

Given the entire schema of the database to complete depth, it would be extraordinarily useful to expose it in its entirety for consumers of the API for tab completion via typescript or graph-ql interactions as well as more detailed and complete data models in the swagger ui.

Ship internal schema with library

If we utilize @context & @type, we can provide @type given that @context is what we expect, passing through fetch.

This is important so that the schemas don't need to be re-downloaded again and again

Integrate typescript-driven schema validation into this repo

https://github.com/dcic/signature-commons-metadata-api/blob/master/src/util/validate.ts

Schema unification with JSON-LD Frames

Utilizing this we can devise two-way conversions between a unifying schema and independent schemas used by external applications and databases.

Python library for sigcom $validator-aware validation