I think just that you won't (necessarily) ever code such classes. They are domain concepts, not software entities. It's very tempting to translate them to software but often not the best possible idea, so it's good to keep in mind which kind of objects you're dealing with at any time.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Conceptual domain modeling is often thought of as a data modeling effort, which happens to be how I present it in that essay, but the reality is that it is orthogonal to the technologies employed. You want to explore the domain concepts like this on an object project as well as on a data project. In fact, in my example I use UML notation to show that it can be done. At http://www.agilemodeling.com/essays/phasesExamined.htm I include a diagram which shows that a wide range of models could be used for this purpose.