6. Constraints with SHACL | Semantic Layer course

Section 1

The application that should have been stopped

Next section

Section 2

Open world and closed world

Next section

Section 3

Writing shapes

Next section

Section 4

Severity, messages, and the applicant shape

Next section

Section 5

Which one complains?

Next section

Section 6

The validation report is your audit trail

Next section

Section 7

Three places validation runs

Hands on

Catch the bad loan data

25 min

Write shapes.ttl, run pySHACL against the Meridian graph, get violations for Tobias's missing KYC document and an out-of-range credit score, then fix the data and get sh:conforms true.

make lab-up            # once, starts Postgres + Fuseki + Ontop
make lab lab06-shacl-gate

Full instructions, starter files and the solution are in labs/modules/lab06-shacl-gate/README.md. The lab checks its own work, so you will know if it passed.

Check yourself

Quiz

7 questions, pass mark 70%. Answers are explained either way, so a wrong guess is not wasted.

1 Application APP-9002 has no KYC document linked. An OWL reasoner reports the graph is consistent. Why?

The reasoner has a bug in its cardinality handling OWL uses the open-world assumption, so a missing triple means not stated rather than false, and the reasoner assumes the document exists somewhere it has not been told about OWL only validates classes, never properties The KYC requirement was written as a Warning rather than a Violation

2 Which two are true about the difference between owl:minCardinality 1 and sh:minCount 1 on the same property? (pick two)

Select all that apply.

owl:minCardinality lets a reasoner conclude some value exists even when none is present in the graph sh:minCount reports a violation when no value is present in the graph They are equivalent and the choice is purely stylistic sh:minCount causes the triple store to reject the write at insert time

3 You need a rule saying a loan with a write-off date must have days past due of 90 or more. Why does this need sh:sparql rather than core SHACL constraints?

Core SHACL cannot handle integers It compares two different properties on the same node, and core constraint components each check a single property path sh:sparql is faster for numeric comparisons Write-off dates are not part of the ontology

4 Meridian marks a missing or non-positive annual income as sh:Warning rather than sh:Violation. What is the reasoning?

Warnings run faster than violations Warnings surface the record for a human to check without blocking the whole nightly load for records that are probably legitimate Income is not part of any competency question sh:Violation is only valid on object properties

5 Which field of a SHACL validation result tells you which specific constraint rule fired?

sh:focusNode sh:resultPath sh:sourceConstraintComponent sh:conforms

6 Why does Meridian run SHACL validation on the asserted graph before running the reasoner, rather than after?

The reasoner deletes triples that SHACL needs Domain and range axioms would infer the very types the sh:class constraints are checking for, so validation would pass on data the reasoner repaired rather than data anybody supplied pySHACL cannot read inferred triples SHACL and OWL cannot run in the same triple store

7 In the LoanApplicationShape, why is the KYC requirement written with sh:qualifiedValueShape and sh:qualifiedMinCount 1 instead of a plain sh:minCount 1 on mrb:evidencedBy?

Plain sh:minCount is deprecated in SHACL Plain sh:minCount would be satisfied by any document, such as a payslip, whereas the qualified form demands that at least one of the values be specifically a KYC document sh:qualifiedMinCount produces a better error message automatically mrb:evidencedBy can only be used with qualified shapes