1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
use ;
use Debug;
use Hash;
/// A concept — a type representing a kind of thing in an ontology.
///
/// Corresponds to Guarino (2009) *Formal Ontology in Information Systems*'s
/// "universal" and OWL's "class": a shared essence that instances can
/// inhabit. A concept's *variants* play the role of both finer-grained
/// sub-concepts and (in closed-world ontologies) the only individuals — there
/// is no separate runtime individual layer.
///
/// # Open-world by default
///
/// `Concept` itself makes **no** finiteness commitment: it carries only the
/// supertrait bounds (`Sized + Clone + Eq + Hash + Debug + 'static`) and a
/// lexical [`name`](Concept::name). This is the open-world case (Reiter 1978):
/// a concept may be inhabited by individuals that exist only at runtime — e.g.
/// the vertices of an ontology materialized from a loaded `.prx`, which the
/// type system cannot enumerate at compile time.
///
/// Finite enumeration lives in the [`FinitelyGenerated`] subtrait, which adds
/// `variants()`. Closed-world concepts (the macro-derived enums) implement both
/// `Concept` and `FinitelyGenerated`; open-world concepts implement only
/// `Concept`. The split lets a generic algorithm demand finite enumeration
/// exactly where it iterates (`T: FinitelyGenerated`) and stay open-world
/// everywhere else (`T: Concept`).
///
/// Can be derived for enums with unit variants — the derive emits **both**
/// `Concept` and `FinitelyGenerated`:
/// ```text
/// use pr4xis::category::{Concept, FinitelyGenerated};
///
/// #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Concept)]
/// enum Color { Red, Green, Blue }
///
/// assert_eq!(Color::variants().len(), 3);
/// ```
///
/// # Literature
///
/// - Guarino (2009) §2 — concepts as specifications of conceptualizations
/// - Masolo et al. (2003) WonderWeb D18 — DOLCE's universal/particular split
/// - Smith (2015) *Basic Formal Ontology* — continuants and occurrents
/// - ONTOLEX-Lemon (W3C 2016) — names as lexical entries
/// - Mac Lane (1971) III.5 — coproducts (sum types) and their generators
/// - Reiter (1978) *On Closed World Data Bases* — the closed/open-world split
/// Marker trait for [`Concept`]s whose variants form a **finite generator
/// set** for a free monoid (equivalently, a free sum type / coproduct with
/// a finite generator family).
///
/// # Why this exists
///
/// "Finitely generated" is the standard algebraic / categorical term for
/// a structure whose elements are producible by applying operations to a
/// finite generator set. It's load-bearing across algebra and category
/// theory:
///
/// - **Lang** *Algebra* (3rd ed., Graduate Texts in Math 211, 2002) §I.2
/// — finitely generated groups / modules / algebras
/// - **Howie** *Fundamentals of Semigroup Theory* (1995) §1.2 — "a monoid
/// M is finitely generated iff there exists a finite subset S ⊂ M such
/// that every element of M can be written as a product of elements of S"
/// - **Clifford & Preston** *The Algebraic Theory of Semigroups* (1961)
/// Ch. 1 — same definition for semigroups
/// - **Mac Lane** *Categories for the Working Mathematician* (1971) VII.3
/// — free monoids and generators; III.5 — coproducts as free sum types
/// - **Adámek & Rosický** *Locally Presentable and Accessible Categories*
/// (1994) — finitely presentable / finitely generated objects
/// - **Fong & Spivak** *Seven Sketches in Compositionality* (2019) Ch. 3
/// — finitely presented categories via generators and relations
/// - **Eilenberg** *Automata, Languages, and Machines* (1974) A.III — free
/// monoids on finite alphabets, the canonical finitely-generated case
/// - **Ganter & Wille** *Formal Concept Analysis* (1999) — concepts
/// generated by (finite) attribute sets
///
/// # In pr4xis
///
/// This subtrait carries the finite enumeration: `variants()` lives here, **not**
/// on [`Concept`]. That realizes the closed/open-world split (Reiter 1978 *On
/// Closed World Data Bases*) in the type system — closed-world concepts (the
/// macro-derived enums) are `FinitelyGenerated`; open-world concepts
/// (potentially-infinite or runtime-instantiated, e.g. vertices materialized
/// from a loaded `.prx`) implement only `Concept` and therefore cannot be
/// enumerated. A generic algorithm asks for `T: FinitelyGenerated` exactly
/// where it iterates the generators, and stays open-world (`T: Concept`)
/// everywhere else.
///
/// There is deliberately **no** default `variants()`: a silently-empty
/// enumeration is a footgun (it would make every open-world concept look like
/// the empty closed-world ontology). Implementors must supply the real
/// generator set; the derive macro does so for unit enums.
/// Metadata about concept variants — generated by the derive macro
/// from `/// doc comments`. Separate from the [`Concept`] trait because
/// descriptions are metadata ABOUT the concept, not behavior OF it.
///
/// The derive macro generates a const `<TypeName>_META: &[ConceptMeta]`
/// for each concept enum. The vocabulary system reads it.