Skip to content
Snippets Groups Projects
New look: Off

[System/Core] Schema Service

    • Closed Issue created by Stephen Whitley (Invited Expert) @stephenwhitley

    The schema service is both an implementation of the schema standard defined below and a service to help create, manage and share schemas between different users. It aims to both raise awareness of the different models used by teams to help reuse both of the data sources but also of the schemas themselves. This will hopefully help reduce the friction obtaining data from multiple sources.

    Schema service goals:

    • To enable easier creation of new schemas
    • To discover popular schemas in use today
    • To make reuse of existing schemas easier to achieve

    Schema Definition: A schema is the model definition for a particular entity. At its core it defines the property names, their types and relationships to other models. It also includes certain qualities to expect about the actual entities and the data its hold.

    An entity is a specific instance of a schema. A schema is assigned an entityType which categorizes the data the schema defines. For example 'well' is an example of an entityType.

    An entityType is assigned an 'authority'. An authority is a namespace to help differentiate types defined by different groups e.g. it allows for both an slb:well and a chevron:well type to exist.

    With schema definitions we aim to define the standards for data models used by a DDMS. This will reduce the friction with different systems data sharing needs helping with our vision to enable data discovery and sharing.

    Principles:

    • Low threshold for Schema Registration : We should make it as easy as possible to create a new schema and register it, Whether this be through examples, tooling to help auto-generate a schema or validators to give early feedback when invalid markup is used. Also it must be easy to reuse existing schema definitions - DE-schemas and external schemas - using composition.
    • Easy to consume : JSON schema allows for JSON pointers to other schema parts and fragments, which need to be chased to obtain a full schema. A registered DE schema is self-contained, i.e. it contains only internal references "
      There was an error rendering this math block. KaTeX parse error: Expected 'EOF', got '#' at position 8: ref": "#̲/definitions/..…
      ref" are resolvable. Consumers find all the answers inside the single schema document. The schema has a predictable structure.
    • Robust : All Schemas are read-only and versioned. The major version is controlled by the schema producer, the minor version is controlled by the schema service. When a schema is assigned version 1.0.0 or higher no breaking changes can be applied on new schema versions. Breaking changes will be allowed on any schema version with major version 0.X.X.
    • Breaking changes are: - removed properties - changes to existing properties e.g.changed types, changed required properties : This gives consumers confidence that they can use data without fear of breaks in the future. However schemas can be deprecated meaning that no new data will be assigned to it.

    Schema attributes Schema definitions are based on in the JSON schema standard and OpenAPI 3. There are subtle differences in the keyword support, which are explained in conjunction with OAS3 here.

    • AWS
    • Azure
    • IBM
    • GCP
    3 of 4 checklist items completed · Edited

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply