OO-LD / schema

The Object Oriented Linked Data Schema
Creative Commons Zero v1.0 Universal
8 stars 0 forks source link

Inheritance, Composition and Mixins #9

Open simontaurus opened 3 months ago

simontaurus commented 3 months ago

See also https://linkml.io/linkml/schemas/inheritance.html#mixin-classes-and-slots and https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem. The diamond problem does not apply to JSON-SCHEMA since every schema included by allOf needs to be valid on the target document, meaning the following schema is invalid in any case:

allOf:
- title: B
  properties:
    x:
      title: xB
      type: integer
- title: C
  properties:
    x:
      title: xC
      type: string

This make sense also in case of beeing transferred to e.g. python dateclasses because otherwise casting from a more specific to a more general base class would not be possible. The need to allow incompatible definitions applies actually only to annotations (like title, descriptions, etc) and class methods (out-of-scope for JSON-SCHEMA). In this case, the order of superclasses becomes important, e.g.

allOf:
- title: B
  properties:
    x:
      title: xB
      type: integer
      minimum: 1
- title: C
  properties:
    x:
      title: xC
      type: integer
      maximum: 10

will generate a web form with xB as label for x and a code generator will create

class Model(BaseModel):
    x: Optional[conint(ge=1, le=10)] = Field(None, title="xB")

Consistently,

class B:
    def echo(self):
        print("xB")

class C:
    def echo(self):
        print("xC")

class D(B,C):
    pass

D().echo()

will result in xB.

Other then the order with allOf there's no intrument in JSON-SCHEMA to indicate primary and secundary superschemas / classes. $ref could be regarded to have a different semantics as allOf: $ref but only a single value is allowed for $ref.