Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Slot Usage and Facets

This chapter works Step 6 of Ontology Development 101 (Noy & McGuinness, 2001 — “N&M”) for the wine ontology. The slots exist; now they get their constraints: which values are allowed, which slots must be filled, and what bounds a value must respect. Chapter 5 left everything deliberately loose, so every tightening here has to state its justification.

Noy & McGuinness 2001 — §Step 6

Slots can have different facets describing the value type, allowed values, the number of the values (cardinality), and other features of the values the slot can take.

The value sets

The three characteristic slots Chapter 5 left as strings become enumerations, and their values deserve honest attribution. flavor gets N&M’s set exactly: the paper says “the flavor slot can take on one of the three possible values: strong, moderate, and delicate.” For body and sugar the paper enumerates no complete set; its examples use light and full bodies (the Figure 5 instance has “a light body”; full is their default-value example) and dry and sweet sugars (the same instance is dry; the Port class inherits SWEET from Dessert wine). We complete each scale with the conventional middle value (medium body, off-dry sugar) and say so, rather than passing the full sets off as the paper’s.

Each permissible value also carries its own definition in the schema. An enum whose values are bare tokens makes the reader guess what off-dry means; the definition is one line, and it belongs to the artifact. The slot descriptions get the same treatment: “the color of a wine kind” the slot named color on the class Wine already says twice, so the description says what the characteristic is (the hue the wine presents, imparted chiefly by skin contact during maceration) instead of restating the name or the values.

The color enumeration itself needed no new values here: Chapter 5 already gave it those, because Chapter 4’s subtype-versus-value decision demanded them.

The cardinality sweep

Noy & McGuinness 2001 — §Step 6, cardinality

Sometimes it may be useful to set the maximum cardinality to 0. This setting would indicate that the slot cannot have any values for a particular subclass.

Chapter 5’s lenient stance holds unless something demands otherwise. Four slots earned required:

  • made_from_grape: the paper’s own call. It gives the grape slot a minimum cardinality of one, because every wine is made from at least one variety.
  • wine and food on PairingRecommendation: a recommendation about nothing is not a recommendation, and every pairing question (CQs 3–5) traverses both.
  • name: every competency question addresses its entities by name, and Chapter 7’s instances will be keyed by it.

Everything else stays optional: a wine kind with an unknown body is still a wine kind. The maximum-cardinality-zero facet N&M describe has no work to do in a flat hierarchy: it exists to switch a slot off for a particular subclass, and there are no subclasses to switch it off for. The same is true of default values (the paper’s example: full as a default body); a default is an application convenience, and no competency question asks for one.

confidence gets bounds instead of cardinality: minimum_value: 0, maximum_value: 1. Chapter 5’s prose said “from 0 to 1”; now the schema checks it.

What slot_usage is for, and why it sits idle here

LinkML’s slot_usage narrows an inherited slot for one class: a subclass tightens the range, the cardinality, or the values of a slot it shares with its siblings. That is the natural home of Step 6 work in a schema with deep hierarchies. This schema does not have one: each slot attaches to exactly one class, and the only shared slot (name) needs no narrowing anywhere. So the facets in this chapter land directly on the slot definitions, and slot_usage waits for the schema that needs it (worth knowing before assuming a Step 6 must produce one).

Property characteristics get the same honest treatment. Nothing in the wine schema is symmetric, transitive, or reflexive (N&M’s inverse-slot example, produces on Winery, is exactly what Chapter 5’s no-inverses policy declined), so the OWL-DL rule (a transitive property must stay “simple,” free of cardinality and asymmetry claims) is satisfied without effort. It starts to matter the day a relation like part of enters the schema.

The constraints

The diff below also carries a cleanup. The slot and enum descriptions had accumulated references to the book: chapter numbers, the paper’s name for a term, what a later chapter would do. A schema outlives its book. The description fields ship with the artifact (into the generated docs, the RDF, and any downstream graph), so they now read as self-contained domain documentation, and the book-facing context lives where it belongs: in comments and callout markers, which never enter the artifact’s data.

The schema growth, against the Chapter 5 snapshot:

Listing 6.1
--- wine-yaml-v3
+++ wine-yaml-v4
@@ -2,16 +2,16 @@
 name: wine
 description: |-
   A worked-example ontology of food and wine, built following Ontology
   Development 101 (Noy & McGuinness, 2001) adapted to LinkML and grounded
   in BFO 2020 (ISO/IEC 21838-2:2020) and the Common Core Ontologies (CCO).
-  Following N&M's own running example, it represents wines, foods, and
-  the characteristics that make a wine appropriate for a dish. It is
+  Following the paper's own running example, it represents wines, foods,
+  and the characteristics that make a wine appropriate for a dish. It is
   built for applications that suggest good wine-and-food combinations.
-  See the book for the chapter-by-chapter build.
+  The accompanying book documents the build.
 license: https://creativecommons.org/licenses/by/4.0/
 version: 0.1.0-dev
 
 prefixes:
   # The LinkML metamodel and this schema's own namespace
   linkml: https://w3id.org/linkml/
@@ -22,14 +22,15 @@
   cco: https://www.commoncoreontologies.org/
 
 default_prefix: wine
 default_range: string
 
 # Only linkml:types is imported. External OWL ontologies (BFO, CCO, ...)
-# are reused by URI via class_uri/slot_uri plus the prefixes above —
-# never via imports:, which is reserved for other LinkML schemas.
+# are reused by URI (subclass_of to the external term, resolved through
+# the prefixes above), never via imports:, which is reserved for other
+# LinkML schemas.
 imports:
   - linkml:types
 
 classes:
 
@@ -83,23 +84,23 @@
     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).
+      of wine" sense is deliberately out of scope.
     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).
+      pair rather than as a property of the wine.
     subclass_of: cco:ont00000958
     slots:
       - name
       - wine
       - food
       - rationale
@@ -108,53 +109,58 @@
 
 slots:
 
   name:
     description: >-
-      The name of a kind, place, producer, or recommendation. Every
-      class carries it; instances are named kinds (Chapter 4).
+      The name by which a kind, place, producer, or recommendation is
+      known. Every class carries it.
     range: string
+    # required: every competency question addresses its entities by name.
+    required: true
 
   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.
+      The hue a wine kind presents, imparted chiefly by the extent of
+      grape-skin contact during maceration and shifted by variety and
+      age.
     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
+      The perceived weight and fullness of a wine kind on the palate,
+      driven by alcohol, extract, and residual sugar.
+    range: BodyEnum
 
   flavor:
+    # "bouquet" names the same characteristic in one competency question.
     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
+      The intensity of the taste and aroma impression a wine kind
+      makes.
+    range: FlavorEnum
 
   sugar:
+    # "sugar" is the source paper's name for what is often called sweetness.
     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
+      The residual sugar a wine kind retains after fermentation,
+      perceived as its sweetness.
+    range: SugarEnum
 
   made_from_grape:
     description: >-
       The grape variety or varieties a wine kind is made from.
     range: Grape
     multivalued: true
+    required: true
 
   maker:
     description: >-
-      The winery that makes a wine kind, N&M's name for the
-      wine-winery relationship.
+      The winery that makes a wine kind.
     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
@@ -169,17 +175,20 @@
 
   wine:
     description: >-
       The wine kind a pairing recommendation is about.
     range: Wine
+    # required: a recommendation about nothing is not one.
+    required: true
 
   food:
     description: >-
       The food kind a pairing recommendation is about.
     range: Food
+    required: true
 
   rationale:
     description: >-
       Why the pairing works, in prose.
     range: string
 
@@ -190,17 +199,56 @@
     range: string
 
   confidence:
     description: >-
       How strongly the source backs the pairing, from 0 to 1.
     range: float
+    minimum_value: 0
+    maximum_value: 1
 
 enums:
 
   WineColorEnum:
     description: >-
-      The color values of a wine kind: values of the color
-      characteristic rather than subclasses of Wine (Chapter 4).
+      The hue classifications a wine kind can present.
     permissible_values:
       red:
+        description: Fermented with extended contact between juice and dark grape skins.
       white:
+        description: Fermented with minimal skin contact, typically from pale-skinned grapes.
       rosé:
+        description: Fermented with brief skin contact, sitting between white and red.
+
+  BodyEnum:
+    description: >-
+      The palate-weight classifications of a wine.
+    permissible_values:
+      light:
+        description: Low perceived weight on the palate.
+      medium:
+        description: Intermediate perceived weight on the palate.
+      full:
+        description: High perceived weight, typically with higher alcohol and extract.
+
+  FlavorEnum:
+    description: >-
+      The taste-and-aroma intensity classifications of a wine.
+    permissible_values:
+      delicate:
+        description: A subtle, low-intensity impression.
+      moderate:
+        description: An intermediate-intensity impression.
+      strong:
+        description: A pronounced, high-intensity impression.
+
+  SugarEnum:
+    description: >-
+      The residual-sugar classifications of a wine.
+    permissible_values:
+      dry:
+        description: Little or no perceptible residual sugar.
+      off-dry:
+        description: Slightly perceptible residual sugar.
+      sweet:
+        description: Clearly perceptible residual sugar.

The new enumerations carry their attribution 6.1.4 in the schema itself; made_from_grape records N&M’s minimum-cardinality call 6.1.2; and confidence turns Chapter 5’s prose promise into a checked constraint 6.1.3.

The schema is now structurally complete: classes, slots, values, and constraints. What it does not yet have is anything in it. Chapter 7 creates the instances the competency questions name, validates the lot, and asks the only question that finally matters: can the ontology answer what Chapter 1 said it would?