This PR adds the concept of a "registry" as a Pydantic class containing one field per Semantic Property. This is so we can produce a JSON Schema for the registry itself, i.e. a machine readable format that we can then use to ensure the consistency of our component and payload models.
Each property is represented as a type with some extensions (via the usage of Annotated), following the Pydantic mechanisms we've been using so far in the Semantic Core.
I haven't created a new version of the schemas (not worth it until we stabilize these concepts), but I did create a draft which produced:
{
"$defs": {
"PoliciesEnum": {
"enum": [
"GDPR",
"CCPA",
"HIPAA"
],
"title": "PoliciesEnum",
"type": "string"
}
},
"properties": {
"is_sensitive": {
"aspect": "security",
"description": "Indicates if the field associated with this property contains sensitive data or not.",
"internal_description": "Sensitive data has some implications that T&S must define.",
"is_internal": false,
"title": "Is Sensitive",
"type": "boolean"
},
"data_policies": {
"aspect": "security",
"description": "Data policies that apply to the field.",
"is_internal": false,
"items": {
"$ref": "#/$defs/PoliciesEnum"
},
"title": "Data Policies",
"type": "array"
}
},
"required": [
"is_sensitive",
"data_policies"
],
"title": "PropertiesRegistry",
"type": "object"
}
This PR adds the concept of a "registry" as a Pydantic class containing one field per Semantic Property. This is so we can produce a JSON Schema for the registry itself, i.e. a machine readable format that we can then use to ensure the consistency of our component and payload models.
Each property is represented as a type with some extensions (via the usage of
Annotated
), following the Pydantic mechanisms we've been using so far in the Semantic Core.I haven't created a new version of the schemas (not worth it until we stabilize these concepts), but I did create a draft which produced: