Specification by Example

Response 4: Validating Specification by Example[edit]

Gemini: Your argument bridges the gap between the theoretical "softness" of the first text Competency_Questions_versus_Graph_Walks and the engineering practicality of the second Unit Tests for Ontologies1

. Here is how your concepts of **Specification by Example** and **Relevance** transform the ideas found in the papers.

1. Specification by Example vs. Definition[edit]

You argue that Examples (Instances) must constrain Definitions (Ontology).

• The Conflict: Gruninger & Fox (Text 1) prioritize Specification by Definition. They define "axioms" first (the definition) and assume valid instances will follow.
• The Solution: Vrandečić & Gangemi (Text 2) support your view. In Section 2, they describe the "Professor/University Member" error. The definition was changed (University Member removed), but the example (the actual Professor instance on the web page) disappeared.
  • The Unit Test ([math]T+[/math]) acts as the Specification by Example. If the ontology definition ([math]O[/math]) generates a state that contradicts the example ([math]T+[/math]), the definition is rejected.
  • This confirms your argument: The definition is allowed to be abstract, provided it never contradicts the concrete examples.

2. The Relevance Idea (Bounded Contexts)[edit]

You argue that global consistency is irrelevant; only the "use-case specific subset" matters.

• The Anti-Pattern (Text 1): Gruninger & Fox aim for a "Common Sense Enterprise Model" (Section 3) meant to be valid for the entire enterprise. This leads to the "Software Frustration" you mentioned—the system tries to validate the whole world and hits complexity walls (NP-Complete).
• The Support (Text 2): Vrandečić & Gangemi (Section 3) implicitly support your relevance filter. They note that the Negative Test Ontology ([math]T-[/math]) can be locally contradictory.
  • "There are two sets of axioms... that contradict each other. This still makes sense... O must be agnostic."
  • This validates your method: The "Global World" ([math]T-[/math]) contains contradictions, but as long as your specific subset ([math]O[/math]) does not derive the wrong specific fact, the system passes. You filter out the irrelevant contradictions of the larger world.

3. Hardware vs. Software (The Case for Subsetting)[edit]

You argue that hardware is sufficient for specific subsets, but software fails to manage the scope.

• Text 2 (Section 5) addresses this via "Expressive Consistency Checks." It suggests that heavy logic (Validation) should be separated from the runtime ontology.
  • By creating a "Use-Case Specific Subset" (what the text calls a "Lightweight Ontology"), you ensure the dataset fits within the "bounds of what the system can manage."
• Graph Walks as the Tool: A Graph Walk effectively enforces this subsetting. It only loads the nodes reachable by the specific use case (the walk), ignoring the irrelevant (and potentially contradictory) data in the rest of the graph. It utilizes the hardware efficiently (Linear RAM usage) rather than the software inefficiency of a global logic reasoner.

Synthesis for your Argument[edit]