Apply semantic ontology rules to knowledge graphs to infer new relationships and facts from explicit definitions.
This skill enables comprehensive ontology reasoning by applying RDF/OWL-based inference rules that automatically expand knowledge graphs through class hierarchies, property inheritance, and semantic constraints.
Hierarchical organization of concepts with subclass relationships.
Thing (root)
├── PhysicalObject
│ ├── Vehicle
│ │ ├── Car
│ │ │ └── ElectricCar
│ │ └── Truck
│ └── Animal
│ ├── Mammal
│ └── Bird
└── AbstractConcept
Properties: Inheritance, specialization, polymorphism
Individuals are instances of classes; inheritance propagates membership.
tesla:Individual
type: ElectricCar
(inherited) type: Car
(inherited) type: Vehicle
(inherited) type: PhysicalObject
(inherited) type: Thing
Properties have domain (source class) and range (target type).
Property: hasOwner
domain: Vehicle # hasOwner applies to Vehicles
range: Person # hasOwner points to Person
inverse: owns # owns is inverse of hasOwner
Property: hasColor
domain: PhysicalObject
range: Color
Subclasses inherit property definitions from parent classes.
Vehicle.hasOwner → Car.hasOwner (inherited)
Vehicle.hasColor → ElectricCar.hasColor (inherited)
Properties with inverse relationships (e.g., hasOwner ↔ owns).
A hasOwner B ⇒ B owns A (by inverse property)
married_to inverse married_to ⇒ A married_to B ⇒ B married_to A
Properties where chaining implies relationship.
transitiveProperty: partOf
A partOf B ∧ B partOf C ⇒ A partOf C
transitiveProperty: locatedIn
Paris locatedIn France ∧ France locatedIn Europe ⇒ Paris locatedIn Europe
If X is instance of A and A is subclass of B, then X is instance of B.
IF
X instance_of A
A subclass_of B
THEN
X instance_of B
Example:
tesla instance_of Car
Car subclass_of Vehicle
⇒ tesla instance_of Vehicle
Application: Materializing full class hierarchy for each individual
If property P has domain D and P is used with subject S, then S is instance of D.
IF
property P has domain D
S P O
THEN
S instance_of D
Example:
hasOwner domain Vehicle
john_car hasOwner jane
⇒ john_car instance_of Vehicle
If property P has range R and P is used with object O, then O is instance of R.
IF
property P has range R
S P O
THEN
O instance_of R
Example:
hasOwner range Person
john_car hasOwner jane
⇒ jane instance_of Person
If property P belongs to class A, and B is subclass of A, then property P belongs to B.
IF
class A has property P
B subclass_of A
THEN
class B has property P
If property P is subproperty of Q and (S P O), then (S Q O).
IF
P subproperty_of Q
S P O
THEN
S Q O
Example:
son subproperty_of child
alice son bob
⇒ alice child bob
If property P is inverse of Q and (S P O), then (O Q S).
IF
P inverse_of Q
S P O
THEN
O Q S
Example:
hasOwner inverse_of owns
vehicle hasOwner person
⇒ person owns vehicle
If property P is symmetric and (S P O), then (O P S).
IF
P is symmetric
S P O
THEN
O P S
Example:
knows symmetric
alice knows bob
⇒ bob knows alice
If property P is transitive and (S P M) and (M P O), then (S P O).
IF
P is transitive
S P M
M P O
THEN
S P O
Example:
ancestor transitive
alice ancestor bob
bob ancestor charlie
⇒ alice ancestor charlie
Eagerly apply all inference rules to derive complete closure.
Algorithm:
1. Load ontology and individuals
2. Apply rules iteratively until fixpoint
3. Store all inferred facts
4. Index for fast querying
Pros: Complete, fast queries
Cons: Storage cost, upfront computation
Best For: OLAP, offline reasoning
Query-driven inference - derive facts only when queried.
Algorithm:
1. Receive query for fact
2. Check explicit facts
3. If not found, apply rules backward
4. Return proof or empty
Pros: Storage efficient, on-demand
Cons: Query latency, repeated computation
Best For: OLTP, large graphs
Combine materialization for common facts with backward chaining for rare ones.
Materialize: Subclass membership, property domain/range
Backward chain: Transitive closure, complex paths
Verify property domain/range constraints.
hasOwner domain Vehicle
john_car hasOwner "red" ← Type violation! "red" is not Person
Ensure no contradictory subclass relationships.
A subclass_of B
B subclass_of C
NOT (C subclass_of A) ← Would create cycle
Enforce cardinality, uniqueness, and other constraints.
hasOwner cardinality 1 ← Each vehicle has exactly one owner
| Issue | Cause | Solution |
|---|---|---|
| ------- | ------- | ---------- |
| Infinite loops | Cyclic properties | Detect cycles, limit depth |
| Memory overflow | Too many inferences | Selective materialization |
| Type violations | Domain/range mismatches | Validation, filtering |
| Inconsistencies | Contradictory rules | Detect, flag, or resolve |
| Performance degradation | Expensive transitive closure | Caching, incremental updates |
| Missing inferences | Incomplete ontology | Augment definitions |
✓ Define ontologies clearly - Use consistent naming and structure
✓ Minimize cyclic dependencies - Design acyclic hierarchies
✓ Choose inference strategy wisely - Match to query patterns
✓ Cache inference results - Reuse computed closures
✓ Validate ontology consistency - Check before inference
✓ Handle inverse properties carefully - Avoid redundant storage
✓ Document semantic assumptions - Clarify rule semantics
✓ Monitor inference performance - Track computation time
✓ Version ontologies - Enable evolution and rollback
✓ Test with sample data - Validate inference correctness
Define domain-specific reasoning beyond OWL.
Support uncertain or probabilistic reasoning.
Time-aware class hierarchies and properties.
Align and reason over multiple ontologies.
Map concepts between different ontologies.
Provide derivation traces and proof chains.
This skill integrates with:
rdflib - RDF/OWL supportowlready2 - OWL ontology reasoningpysparql - SPARQL endpointHermit - OWL reasonerPellet - Description logic reasonerJena - Semantic web frameworknetworkx - Graph algorithmsneo4j - Graph databasevirtuoso - RDF triple storerdflib-jsonld - JSON-LD supportpyshacl - SHACL validationVersion: 1.0.0
共 1 个版本