OWL essentials.

RDFS gives you inheritance. OWL gives you shape.

RDFS lets you declare that Ninja is a subclass of Character, and that senseiOf has domain Ninja. A reasoner derives new class memberships from these rules. OWL adds the ability to say not just what kind of thing something is, but what it must have, what it can only be, and what combinations are impossible.

RDFS: "Every Ninja is a Character." OWL restriction: "Every Ninja must belong to at least one Village." These are different kinds of statements. The first is an inheritance rule. The second is a shape constraint — a restriction on what a thing must look like to count as a member of the class. Restrictions are where ontology design judgment actually lives.

The TBox / ABox distinction.

OWL distinguishes two layers of an ontology:

• TBox (Terminological Box) — the schema layer. Class declarations, property declarations, restrictions. Things that are always true about the domain. naruto:Ninja rdfs:subClassOf naruto:Character is a TBox statement.
• ABox (Assertional Box) — the instance layer. Individual facts. naruto:NarutoUzumaki a naruto:Ninja is an ABox statement.

In OWL, named individuals are explicitly declared members of the ABox: naruto:NarutoUzumaki a owl:NamedIndividual (implicit in OWL when you assert any class membership). The distinction matters because OWL reasoning operates on the relationship between TBox rules and ABox facts to derive new ABox facts.

The Unique Name Assumption is not default in OWL

In a relational database, two different IDs are always different things. OWL does not assume this by default. Two different IRIs might refer to the same individual unless you explicitly assert owl:differentFrom or owl:AllDifferent. This is one reason that queries returning "all distinct pairs" must use FILTER conditions — the reasoner might otherwise conclude that two apparently different individuals are the same.

What you declare about a property determines what fires.

OWL properties carry characteristics that tell the reasoner how to behave when it encounters triples using that property.

In naruto-ontology-starter.ttl, only owl:SymmetricProperty and owl:inverseOf are used. Submodule 2.1 demonstrated both through Protégé. Exercise 2.3 asks you to consider whether any additional characteristics belong in the published ontology.

Shaping what a class member must look like.

OWL restrictions constrain what can belong to a class. A restriction on a class C says: to be a C, an individual must satisfy this constraint on some property. Two fundamental restriction types:

• owl:someValuesFrom — existential restriction: "at least one value of this property must be of this type." A Ninja must have at least one memberOfVillage value that is a Village.
• owl:allValuesFrom — universal restriction: "every value of this property must be of this type." If a Ninja has any hasJutsu value, it must be a Jutsu. (Note: this does not require having any jutsu — it just constrains what jutsu values are permitted.)

# Existential restriction: every Ninja must be in at least one village
naruto:Ninja rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty naruto:memberOfVillage ;
    owl:someValuesFrom naruto:Village
] .

# Cardinality restriction: a Team must have at least one member
naruto:Team rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty naruto:memberOfTeam ;
    owl:minCardinality "1"^^xsd:nonNegativeInteger
] .

These restrictions are intentionally not in the starter ontology. The Module 2 README says: "resist adding restrictions until you have data to validate against — every premature restriction is a future bug." Exercise 2.3 is where you add them after working through the data and confirming they hold.

Five profiles, four tradeoffs.

OWL Full is the most expressive profile — it allows any RDF graph to also be an OWL ontology. But it is undecidable: no algorithm can always compute all its inferences in finite time. The four tractable profiles each carve out a subset of OWL Full that guarantees decidability, at the cost of expressiveness.

The Naruto ontology is designed to stay within OWL DL. Keeping it out of OWL Full means not mixing metaclass and class usage (punning carefully), not allowing arbitrary SPARQL rules as restrictions, and not creating circular class definitions that defeat termination. HermiT can reason over it.

For production systems at scale, EL is the practical choice — Google's Knowledge Graph and the life sciences industry both use EL-profile ontologies. DL is the right choice for a learning project where you want to see the full range of inference behavior.

Where OWL surprises careful designers.

• The transitivity trap. Declaring any property transitive triggers the reasoner to compute a transitive closure. On a large graph — or one that becomes large — this can be O(n³) or worse. The Naruto ontology deliberately avoids transitive properties on naruto:familyOf even though family relationships are conceptually transitive, because the reasoning cost outweighs the benefit. Before declaring transitivity, ask: what does the full transitive closure of this property look like, and how large could it get?
• owl:sameAs collapse. owl:sameAs asserts that two IRIs refer to the same individual — and a reasoner merges all their properties. If you assert naruto:NarutoUzumaki owl:sameAs wikidata:Q25362, every triple about the Wikidata item transfers to your Naruto individual and vice versa. This includes Wikidata's schema:description, its image, its Wikipedia link, and anything else. Unless you actually want full property merging, use skos:exactMatch (Submodule 1.3) which asserts conceptual equivalence without property inheritance.
• Open-world reasoning surprises. If you declare naruto:Ninja owl:someValuesFrom naruto:Village, a reasoner does not conclude that Ninja who lack a village triple are invalid. It concludes there must be some village somewhere that they belong to, possibly unasserted. This "existential introduction" can cause unexpected inferences downstream. SHACL (Submodule 2.3) is the answer.
• Annotation properties vs. object properties. OWL distinguishes owl:AnnotationProperty (metadata, not used in reasoning) from owl:ObjectProperty (used in reasoning). rdfs:label, rdfs:comment, and dcterms:description are annotation properties. If you use them as object properties in restrictions, the reasoner will ignore the restriction. Always check whether a property is an annotation property before writing a restriction over it.

Add a restriction and watch HermiT fire.

This walkthrough adds one OWL restriction to the starter ontology in Protégé, runs HermiT, and observes what changes. Keep the starter TTL open from Submodule 2.1, or reload it.

Five queries — schema inspection and reasoning patterns.

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX owl:  <http://www.w3.org/2002/07/owl#>

SELECT ?property ?label ?characteristic WHERE {
  ?property a ?type ; rdfs:label ?label .
  VALUES ?type {
    owl:ObjectProperty
    owl:DatatypeProperty
    owl:AnnotationProperty
  }
  VALUES ?characteristic {
    owl:SymmetricProperty
    owl:TransitiveProperty
    owl:FunctionalProperty
    owl:AsymmetricProperty
    owl:InverseFunctionalProperty
  }
  ?property a ?characteristic .
  FILTER (LANG(?label) = "en" || LANG(?label) = "")
}
ORDER BY ?label

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

SELECT ?senseiName ?studentName WHERE {
  ?sensei naruto:hasRank naruto:Jonin ;
          naruto:canonicalName ?senseiName .
  OPTIONAL {
    ?sensei naruto:senseiOf ?student .
    ?student naruto:canonicalName ?studentName .
  }
}
ORDER BY ?senseiName

PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>

SELECT ?name (COUNT(?arc) AS ?arcCount) WHERE {
  ?ninja naruto:canonicalName   ?name ;
         naruto:appearsInArc    ?arc .
}
GROUP BY ?name
HAVING (COUNT(?arc) = 3)
ORDER BY ?name

PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>

CONSTRUCT {
  ?a naruto:rivalOf ?b .
  ?b naruto:rivalOf ?a .
}
WHERE {
  ?a naruto:rivalOf ?b .
}

PREFIX schema: <https://schema.org/>
PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>

SELECT ?jutsuName (COUNT(?ninja) AS ?ninjaCount)
       (GROUP_CONCAT(?name; separator=", ") AS ?ninjaNames)
WHERE {
  ?ninja naruto:hasJutsu   ?jutsu ;
         naruto:canonicalName ?name .
  ?jutsu schema:name ?jutsuName .
  FILTER (LANG(?jutsuName) = "en")
}
GROUP BY ?jutsuName
HAVING (COUNT(?ninja) > 1)
ORDER BY DESC(?ninjaCount)

Reading and next steps.