A constraint system for terminusdb

[matko]

We should have the ability to specify constraints that are more advanced than what we now get out of the basic types.

Here's some rough notes with proposed syntax.

[
{ "@type" : "Class",
  "@id" : "User",
  "name" : "xsd:string",
  "age" : "xsd:nonNegativeInteger"
},
{ "@type" : "Class",
  "@id" : "MidLifeInsurance",
  "@inherits" : "InsuranceProduct"
},
{ "@type" : "Class",
  "@id" : "Policy",
  "@constraints": [{"customer": {"age": [{"@lt": 70},
                                         {"@gt": 35}]}},
                   {"insurance_product": {"@type": "MidLifeInsurance"}}],
  "insurance_product" : "InsuranceProduct",
  "customer" : "Customer",
  "start_date" : "xsd:dateTime",
  "end_date" : "xsd:dateTime"
},
]

This gets unwieldy with more constraints though!
So anonymous constraints could be good, but the moment we have more than one constraint it can be good to split them out, give us an opportunity to document them too.

[
{ "@type" : "Class",
  "@id" : "Customer",
  "name" : "xsd:string",
  "age" : "xsd:nonNegativeInteger"
},
{ "@type" : "Class",
  "@id" : "MidLifeInsurance",
  "@inherits" : "InsuranceProduct"
},
{ "@type" : "Class",
  "@id" : "Policy",
  "insurance_product" : "InsuranceProduct",
  "customer" : "Customer",
  "start_date" : "xsd:dateTime",
  "end_date" : "xsd:dateTime"
},

{ "@type": "Constraint",
  "@id": "MidLifeInsuranceAge",
  "@doc": "People with MidLifeInsurance have to be older than 35, and younger than 70",
  "@on": "Policy",
  "@constraints": [{"insurance_product": {"@type": "MidLifeInsurance"}},
                   {"customer": {"age": [{"@lt": 70},
                                         {"@gt": 35}]}}],

{ "@type": "Constraint",
  "@id": "InsuranceNoOverlap",
  "@doc": "People with an insurance policy can't have that same product in an overlapping duration",
  "@on": "Policy",
  "@constraints": [{"@id": {"@var": "policy_id"}},
                   {"@not": [{"insurance_product": {"@type": {"@var": "product_type_1"}}},
                             {"customer": {"@linked-by": {"@type": "Policy", "@property": "customer},
                                           "@id": {"@var": "policy_id_2"}}},
                             {"@ne": [{"@var": "policy_id"},
                                      {"@var": "policy_id_2"}]},
                             {"@match": {"@id": {"@var": "policy_id_2"},
                                         "insurance_product": {"@var": "product_type_1"}}},
                             {"@match": {"@id": {"@var": "policy_id"},
                                         "start_date": {"@var": "policy_1_start_date"},
                                         "end_date": {"@var": "policy_1_start_date"}}},
                             {"@match": {"@id": {"@var": "policy_id_2"},
                                         "start_date": {"@var": "policy_2_start_date"},
                                         "end_date": {"@var": "policy_2_start_date"}}},
                             {"@or": [{"@between": {"@from": {"@var": "policy_1_start_date"},
                                                    "@to": {"@var": "policy_1_end_date"},
                                                    "@element: {"@var": "policy_2_start_date"}}},
                                      {"@between": {"@from": {"@var": "policy_1_start_date"},
                                                    "@to": {"@var": "policy_1_end_date"},
                                                    "@element: {"@var": "policy_2_end_date"}}}]}]}]
},

{ "@type": "Constraint",
  "@id": "OnlyOneMidLifeInsurance"
  "@doc": "People with a midlife insurance policy can't have that another midlife insurance policy in an overlapping duration",
  "@on": "Policy",
  "@constraints": [{"@id": {"@var": "policy_id"},
                    "start_date": {"@var": "policy_1_start_date"},
                    "end_date": {"@var": "policy_1_end_date"}},
                   {"@not": [{"insurance_product": {"@type": "MidLifeInsurance"}},
                             {"customer": {"@linked-by": {"@type": "Policy", "@property": "customer},
                                           "insurance_product": {"@type": "MidLifeInsurance"},
                                           "@id": {"@var": "policy_id_2"},
                                           "start_date": {"@var": "policy_2_start_date"},
                                           "end_date": {"@var": "policy_2_end_date"}}},
                             {"@ne": [{"@var": "policy_id"},
                                      {"@var": "policy_id_2"}]},
                             {"@or": [{"@between": {"@from": {"@var": "policy_1_start_date"},
                                                    "@to": {"@var": "policy_1_end_date"},
                                                    "@element: {"@var": "policy_2_start_date"}}},
                                      {"@between": {"@from": {"@var": "policy_1_start_date"},
                                                    "@to": {"@var": "policy_1_end_date"},
                                                    "@element: {"@var": "policy_2_end_date"}}}]}]}],

{ "@type": "Constraint",
  "@id": "PolicyDurationEndIsAfterStart",
  "@doc": "The end date of a policy duration has to be after the start date",
  "@constraints": [{"start_date": {"@var": "start_date"},
                    "end_date": {"@var": "end_date"}},
                   {"@gt": [{"@var": "start_date"},
                            {"@var": "end_date"}]}]
}
]

In all these cases we put the constraint on Policy, but some of these constraints actually matched over a bunch of related instances using the @match word. One could imagine a kind of constraint that is actually not linked to any particular type.

From prototyping this it kinda looks like @on is just a way to shortcut, so that we have a default context to match things in. But you could always match an arbitrary type just with @match.

It does kind of seem like this is a partial re-invention of woql. The main difference here is that this is meant to express constraints only. So no mutations of any kind, no transformation of results into fancy documents, just link following and constraints after following those links.

[GavinMendelGleason]

That looks excellent, but we should probably have the documentation follow the same approach as other elements of a schema.

{ "@type" : "Constraint",
  "@id": "MyExampleContraint",
  "@documentation":[
             {"@comment":"An example constraint which does something special",
              "@label":"Example Constraint",
              "@language":"en" },
            {"@comment":"მაგალითი კლასი",
             "@label":"მაგალითი",
             "@language":"ka"} ]
 ...}