SHACL and vocabulary alignment.

Going deeper than the Module 2 introduction.

Submodule 2.3 introduced SHACL as the closed-world answer to OWL's open-world assumption. This submodule goes deeper: the full constraint component vocabulary, SPARQL-based custom constraints, severity levels, and how SHACL fits into a production data pipeline.

The SHACL data model

SHACL defines two kinds of shapes:

• sh:NodeShape — targets specific nodes in the graph (via sh:targetClass, sh:targetNode, sh:targetSubjectsOf, or sh:targetObjectsOf) and applies property constraints to them.
• sh:PropertyShape — a reusable constraint on a specific property, which can be referenced from multiple NodeShapes via sh:property.

# A NodeShape targeting all naruto:Ninja nodes
naruto:NinjaShape
    a sh:NodeShape ;
    sh:targetClass naruto:Ninja ;
    sh:property [
        sh:path     naruto:canonicalName ;
        sh:datatype xsd:string ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:message  "A Ninja must have exactly one canonicalName."@en ;
        sh:severity sh:Violation
    ] ;
    sh:property [
        sh:path     naruto:memberOfVillage ;
        sh:class    naruto:Village ;
        sh:minCount 1 ;
        sh:message  "A Ninja must belong to at least one Village."@en
    ] .

Key constraint components

Severity levels

SHACL has three built-in severity levels, attached with sh:severity:

• sh:Violation — the node does not conform; a data ingestion pipeline should reject it (default if not specified).
• sh:Warning — the constraint is best-practice but not blocking; flag for review.
• sh:Info — informational annotation; not a conformance failure.

Use severity to express policy rather than binary pass/fail. A missing schema:url on an organization might be a Warning; a missing canonicalName on a Ninja is a Violation. Both constraints live in the same shape file.

SPARQL-based constraints

For constraints that basic SHACL components cannot express, sh:sparql allows embedding a SPARQL query that returns violation results.

# Custom constraint: no ninja should be their own sensei
naruto:NinjaShape sh:sparql [
    a sh:SPARQLConstraint ;
    sh:message "A Ninja cannot be their own sensei."@en ;
    sh:severity sh:Violation ;
    sh:select """
        PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>
        SELECT $this WHERE {
            $this naruto:senseiOf $this .
        }
    """ ;
] .

Not all equivalences are equal.

When connecting your graph to an external vocabulary or dataset, the equivalence predicate you choose has consequences that compound through reasoning. The wrong choice is usually owl:sameAs applied where skos:exactMatch should go.

What formal rules can surface that a resume doesn't state.

The Resume Graph Explorer contains explicitly asserted skills — what someone listed on their resume. Formal inference rules can surface skills that are implied by the combination of asserted skills and ESCO's vocabulary structure, or by the duration and nature of work experience.

The inference rules (from the Module 3 README)

# Rule 1: ESCO-related exposure
# If a person has skill X and X is skos:related to Y in ESCO,
# infer sensemaking:hasInferredSkill ?person ?y at "exposure" level.

CONSTRUCT {
  ?person sensemaking:hasInferredSkill ?relatedConcept .
  _:basis a sensemaking:InferenceBasis ;
          sensemaking:inferenceRule "esco-related-exposure" ;
          sensemaking:exposureLevel "exposure" .
}
WHERE {
  ?person sensemaking:hasSkill ?skill .
  ?skill skos:exactMatch/skos:related ?relatedConcept .
  FILTER NOT EXISTS {
    ?person sensemaking:hasSkill ?s2 .
    ?s2 skos:exactMatch ?relatedConcept .
  }
}

# Rule 2: Long-tenure promotion
# If a person held a role for 2+ years AND has a skill at "advanced",
# escalate skos:related concepts from "exposure" to "demonstrated".

CONSTRUCT {
  ?person sensemaking:hasInferredSkill ?relatedConcept .
  _:basis a sensemaking:InferenceBasis ;
          sensemaking:inferenceRule "long-tenure-promotion" ;
          sensemaking:exposureLevel "demonstrated" .
}
WHERE {
  ?person sensemaking:hasEmployment ?emp ;
          sensemaking:hasSkill ?skill .
  ?skill skos:exactMatch/skos:related ?relatedConcept ;
         sensemaking:skillLevel "advanced" .
  ?emp sensemaking:startDate ?start ;
       sensemaking:endDate   ?end .
  FILTER ((?end - ?start) > "P2Y"^^xsd:duration)
  FILTER NOT EXISTS {
    ?person sensemaking:hasSkill ?s2 .
    ?s2 skos:exactMatch ?relatedConcept .
  }
}

Five queries — validation, alignment, and inference.

PREFIX foaf:        <http://xmlns.com/foaf/0.1/>
PREFIX dcterms:     <http://purl.org/dc/terms/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/>

# Simulate a PersonShape validation:
# - Every foaf:Person must have foaf:name (minCount 1)
# - Every sensemaking:Resume must have dcterms:created (minCount 1)
# Find violations: persons without a name

SELECT ?person ?violation WHERE {
  ?person a foaf:Person .
  BIND("missing foaf:name" AS ?violation)
  FILTER NOT EXISTS { ?person foaf:name ?name . }
}
UNION
{
  ?resume a sensemaking:Resume .
  BIND("missing dcterms:created" AS ?violation)
  FILTER NOT EXISTS { ?resume dcterms:created ?date . }
}
ORDER BY ?person

PREFIX foaf:        <http://xmlns.com/foaf/0.1/>
PREFIX skos:        <http://www.w3.org/2004/02/skos/core#>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/>

SELECT ?skillLabel ?hasExactMatch ?relatedCount WHERE {
  ?person a foaf:Person ;
          sensemaking:hasSkill ?skill .
  ?skill skos:prefLabel ?skillLabel .
  FILTER (LANG(?skillLabel) = "en")
  BIND(EXISTS { ?skill skos:exactMatch ?esco . } AS ?hasExactMatch)
  {
    SELECT ?skill (COUNT(?related) AS ?relatedCount) WHERE {
      OPTIONAL { ?skill skos:exactMatch/skos:related ?related . }
    } GROUP BY ?skill
  }
}
ORDER BY DESC(?relatedCount)

PREFIX foaf:        <http://xmlns.com/foaf/0.1/>
PREFIX skos:        <http://www.w3.org/2004/02/skos/core#>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/>

CONSTRUCT {
  ?person sensemaking:hasInferredSkill ?relatedConcept .
}
WHERE {
  ?person a foaf:Person ;
          sensemaking:hasSkill ?skill .
  ?skill skos:exactMatch/skos:related ?relatedConcept .
  FILTER NOT EXISTS {
    ?person sensemaking:hasSkill ?s2 .
    ?s2 skos:exactMatch ?relatedConcept .
  }
}

PREFIX foaf:        <http://xmlns.com/foaf/0.1/>
PREFIX xsd:         <http://www.w3.org/2001/XMLSchema#>
PREFIX skos:        <http://www.w3.org/2004/02/skos/core#>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/>

# Skills inferred at "demonstrated" level:
# person held a role for 2+ years AND the asserted skill is "advanced"
CONSTRUCT {
  ?person sensemaking:hasDemonstratedSkill ?relatedConcept .
}
WHERE {
  ?person a foaf:Person ;
          sensemaking:hasEmployment ?emp ;
          sensemaking:hasSkill ?skill .
  ?skill skos:exactMatch/skos:related ?relatedConcept ;
         sensemaking:skillLevel "advanced" .
  ?emp sensemaking:startDate ?start .
  OPTIONAL { ?emp sensemaking:endDate ?end . }
  BIND(COALESCE(?end, "2026-06-03"^^xsd:date) AS ?effectiveEnd)
  FILTER ((?effectiveEnd - ?start) > "P730D"^^xsd:duration)
  FILTER NOT EXISTS {
    ?person sensemaking:hasSkill ?s2 .
    ?s2 skos:exactMatch ?relatedConcept .
  }
}

PREFIX foaf:        <http://xmlns.com/foaf/0.1/>
PREFIX skos:        <http://www.w3.org/2004/02/skos/core#>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/>

# After running q03 and q04 CONSTRUCTs and loading the results:
# Summary of all inferred skills with their labels
SELECT DISTINCT ?skillLabel ?inferenceType WHERE {
  ?person a foaf:Person .
  {
    ?person sensemaking:hasInferredSkill ?concept .
    BIND("exposure" AS ?inferenceType)
  }
  UNION
  {
    ?person sensemaking:hasDemonstratedSkill ?concept .
    BIND("demonstrated" AS ?inferenceType)
  }
  ?concept skos:prefLabel ?skillLabel .
  FILTER (LANG(?skillLabel) = "en")
}
ORDER BY ?inferenceType ?skillLabel

Where each one wins — and where it doesn't.

This comparison is the consulting-positioning artifact the Module 3 README describes as "highest-leverage." The honest version of the comparison — not a promotional piece for either approach — is what makes it valuable.

The primary project: Resume skill inference.

Exercise 3.4 (primary project B) builds the Jupyter notebook that demonstrates skill inference end-to-end on 5–10 resume profiles and compares formal rules to LLM inference. The query lab above provides the formal rules side. For the LLM side:

The artifact lives at modules/03-reasoning/artifacts/skill-inference/ as a Jupyter notebook. The Module 3 README says this connects directly to the existing narrative synthesizer work — the comparison result is positioning gold for the consulting practice.

Reading, tools, and next module.