Rule sources

• TTL: Direct path to a .ttl file (e.g. shacl_rules/my_view_shacl.ttl).
• JSON: Data contract rule set with quality[].ruleDefinitions (JSON-LD).
• YAML: View config with shacl_rules.file pointing to a TTL file; datamodel and instance space can be defined in the same file.

See SHACL rules and CDF data models for how interfaces and sh:targetClass work with the loaded RDF graph, and what to do if a rule targets a class with zero instances (including the validation-time warning).

TTL

Use a Turtle file directly:

rules_path = "shacl_rules/my_view_shacl.ttl"

Pass datamodel and instance_space (and optional records_config) to run_validation() when using TTL.

JSON rule set

Use a JSON ruleset that contains:

{
  "quality": [
    {
      "ruleSetExternalId": "...",
      "ruleSetVersion": "1.0",
      "ruleDefinitions": []
    }
  ]
}

YAML view config

Use a YAML config that references a SHACL file and data model (same format as view configs under views/):

shacl_rules:
  file: "my_view_shacl.ttl"
datamodel:
  space: "my_space"
  external_id: "MyDataModel"
  version: "v1"
instance_space: "my_instances"

Then run_validation(client=client, rules_path="views/my_view.yaml", rules_format="yaml") infers datamodel and instance space from the file.

Interfaces and target class

When writing SHACL rules for CDF data models, avoid using sh:targetClass with an interface name (e.g. MMSINumber). The RDF graph is built from views, so nodes have concrete view types (e.g. NavigationAid, ShoreStation), not interface types. A rule that targets the interface will match no nodes and never report violations.

When you run validation, the runner warns if any rule targets a class that has zero instances in the graph. See SHACL rules and CDF data models for details and how to fix it (target concrete views or use a SPARQL-based sh:target).