Slots

This chapter works Step 5 of Ontology Development 101 (Noy & McGuinness, 2001 — “N&M”) for the wine ontology. The classes exist; now they get their properties, and the class graph gets its edges. N&M’s rule for what belongs here: “most of the remaining terms are likely to be properties of these classes.”

The policies

Four decisions apply across every slot, settled once:

1. Names come from N&M where the paper supplies them: color, body, flavor, sugar, maker. That quietly settles two naming contests Chapter 3 left open: the paper says sugar (not sugar content or sweetness) and flavor (CQ 6’s bouquet is the same characteristic). made_from_grape keeps the name Chapter 2 already used in prose.
2. The pairing stays reified. There is no direct goes_well_with edge from Wine to Food; the relation lives as the PairingRecommendation’s wine and food slots, per Chapters 2 and 4. A graph derives wine-to-food adjacency by traversing through the recommendation node, which is the point: the node is where the rationale rides.
3. No inverses. A knowledge graph traverses edges in both directions; storing made_by alongside maker would be a second copy of the same fact.
4. Cardinality stays lenient. Nothing is required yet, and only made_from_grape is multivalued (a blend has several varieties). Tightening is Chapter 6’s job, where the competency questions say what must be present.

N&M’s attachment rule (a slot belongs at the most general class that can carry it) applies trivially here: the hierarchy is flat, so each slot attaches to the one class it describes, and only name is shared by all seven.

The characteristics

Wine gets the four intrinsic slots straight from N&M’s list: color, body, flavor, and sugar. Chapter 4’s decision lands in the schema here: color ranges over an enumeration whose values are red, white, and rosé, so “Is Bordeaux a red or white wine?” reads a value off the wine kind. The other three stay strings for now, and that is N&M’s own sequencing rather than laziness: the paper enumerates their allowed values (light, medium, and full body; delicate to strong flavor; sweet, dry, and off-dry) in its Step 6, so this book does too: Chapter 6 turns those strings into enumerations.

One competency question looks like it should strain this design and does not. CQ 6 asks whether a wine’s bouquet or body changes with vintage year, and a characteristic stored on a single wine kind cannot vary. But instances are kinds, and kinds can be as specific as the application needs: the 2017 Napa Zinfandel and the 2018 Napa Zinfandel are two Wine instances with their own body values, N&M’s Sterling Vineyards Merlot logic taken one step further. Chapter 7 demonstrates it.

The provenance wiring

The relationship slots are N&M’s fourth kind of property, and they carry the competency questions about where a wine comes from: made_from_grape (to Grape, multivalued for blends), maker (to Winery), region (to WineRegion), and vintage (to VintageYear).

region is stored rather than derived, and the distinction matters: a wine’s appellation is a fact about the wine kind, not about its producer’s address. A winery in one region can make wine from grapes grown in another, so traversing maker and then asking where the winery sits would answer a different question than the one CQ 7 asks about Napa Zinfandel.

The omission is deliberate too: N&M give Winery a location slot, and this schema does not. No competency question asks where a winery is, and every slot here traces to a demand, the same discipline Chapter 3 applied to terms. The slot is a one-line addition the day a question reaches for it.

The recommendation’s shape

PairingRecommendation gets the slots Chapter 2 promised when it argued the pairing should be an information content entity: wine and food (what the recommendation is about), and rationale, source, and confidence (why, who says so, and how strongly). A bare wine-to-food edge could not carry that payload; a graphRAG workflow retrieves it to explain a pairing, not just assert one.

The graph closes

The schema growth, against the Chapter 4 snapshot:

--- wine-yaml-v2
+++ wine-yaml-v3
@@ -36,51 +36,171 @@
   Wine:
     description: >-
       A kind of wine, distinguished by its grape, provenance, and
       characteristics. Instances are named wine kinds such as Bordeaux
       or Napa Zinfandel, not individual bottles.
     subclass_of: cco:ont00001084
+    slots:
+      - name
+      - color
+      - body
+      - flavor
+      - sugar
+      - made_from_grape
+      - maker
+      - region
+      - vintage
 
   Food:
     description: >-
       A kind of food or dish that a wine can be recommended for, such
       as a seafood dish or grilled meat.
     subclass_of: cco:ont00000307
+    slots:
+      - name
 
   Grape:
     description: >-
       A grape variety used to make wine, such as Cabernet Sauvignon or
       Zinfandel. Instances are varieties, mirroring Wine's
       kinds-as-instances reading.
     subclass_of: obo:BFO_0000030
+    slots:
+      - name
 
   WineRegion:
     description: >-
       A geographic wine-growing region, such as Napa or Bordeaux.
     subclass_of: cco:ont00000472
+    slots:
+      - name
 
   Winery:
     description: >-
       An organization that produces wine.
     subclass_of: cco:ont00001180
+    slots:
+      - name
 
   VintageYear:
     description: >-
       The harvest year a wine is tied to. The "2018 vintage as a batch
       of wine" sense stays out of scope (Chapter 2).
     subclass_of: obo:BFO_0000038
+    slots:
+      - name
 
   PairingRecommendation:
     description: >-
       A recommendation that a wine suits a food, such as Cabernet
       Sauvignon with a seafood dish. Grounded as information about the
       pair rather than as a property of the wine (Chapter 2).
     subclass_of: cco:ont00000958
+    slots:
+      - name
+      - wine
+      - food
+      - rationale
+      - source
+      - confidence
 
 slots:
-  # Step 5+ populate these.
 
+  name:
+    description: >-
+      The name of a kind, place, producer, or recommendation. Every
+      class carries it; instances are named kinds (Chapter 4).
+    range: string
+
+  color:
+    description: >-
+      The color of a wine kind: a characteristic Chapter 2 read as a
+      BFO quality, carried here as a value on the wine.
+    range: WineColorEnum
+
+  body:
+    description: >-
+      The body of a wine kind. A string until Chapter 6 enumerates the
+      values, following N&M's own sequencing.
+    range: string
+
+  flavor:
+    description: >-
+      The flavor of a wine kind (CQ 6 says "bouquet" for the same
+      characteristic). A string until Chapter 6 enumerates the values.
+    range: string
+
+  sugar:
+    description: >-
+      The sugar level of a wine kind, N&M's name for the term the list
+      also carried as sweetness. A string until Chapter 6 enumerates
+      the values.
+    range: string
+
+  made_from_grape:
+    description: >-
+      The grape variety or varieties a wine kind is made from.
+    range: Grape
+    multivalued: true
+
+  maker:
+    description: >-
+      The winery that makes a wine kind, N&M's name for the
+      wine-winery relationship.
+    range: Winery
+
+  region:
+    description: >-
+      The wine region a wine kind comes from (its appellation), stored
+      rather than derived: a winery's address does not determine where
+      its wine's grapes grow.
+    range: WineRegion
+
+  vintage:
+    description: >-
+      The harvest year a wine kind is tied to. Vintage-specific kinds
+      (the 2018 Napa Zinfandel) are themselves valid Wine instances.
+    range: VintageYear
+
+  wine:
+    description: >-
+      The wine kind a pairing recommendation is about.
+    range: Wine
+
+  food:
+    description: >-
+      The food kind a pairing recommendation is about.
+    range: Food
+
+  rationale:
+    description: >-
+      Why the pairing works, in prose.
+    range: string
+
+  source:
+    description: >-
+      Where the recommendation comes from (a sommelier, a text, a
+      dataset).
+    range: string
+
+  confidence:
+    description: >-
+      How strongly the source backs the pairing, from 0 to 1.
+    range: float
+
 enums:
-  # Step 5 populates these (the color values, once the color slot exists).
+
+  WineColorEnum:
+    description: >-
+      The color values of a wine kind: values of the color
+      characteristic rather than subclasses of Wine (Chapter 4).
+    permissible_values:
+      red:
+      white:
+      rosé:

The slot section header 5.1.1 marks N&M’s remaining-terms rule; the color enumeration 5.1.2 lands the Chapter 4 decision; made_from_grape 5.1.3 carries the one multivalued call; and the recommendation’s wine slot 5.1.4 records the reification policy where it binds.

And the check Chapter 4 could only promise now passes: with the slots in place, the class graph has edges, and every one of the seven classes is connected: Wine reaches Grape, Winery, WineRegion, and VintageYear directly, and Food joins through PairingRecommendation. No islands: nothing in the schema exists that the worked example does not wire to everything else. Chapter 6 tightens what these slots allow; Chapter 7 fills them with the instances the competency questions name.