Mike and Igor, I'm glad that you mentioned design patterns. But instead of an ontology of design patterns, I would say that design patterns should be the BASIS for ontology. In fact, I would point out that visualization and conceptualization are the basis for mathematics. The formal notation always comes at the end, never at the beginning. The term 'design pattern' is for the kinds of visualizations that mathematicians and logicians start with. The formal notations are essential, but creative mathematicians always start with visual patterns long before they get down to the formal details. In fact, mathematicians usually have the problem completely solved in diagrams long before they work out the formal notations. The formalism is essential to verify that the visualization is correct and to specify every last detail. And the task of writing out the formal details can often point out issues that were missing or mistaken in the visualization. Visualization is the essence of mathematics. Formalization is the housekeeping that is important for keeping everything neat and tidy. More generally, I would emphasize the trio of Conceptualization, Analysis, and Formalization. We need all three. For comments by Paul Halmos (a former president of the American Mathematical Society) and Albert Einstein, see the following slide 27. For more discussion and references, see https://jfsowa.com/talks/eswc.pdf . ---------------------------------------- From: "Mike Bennett" <mbennett(a)hypercube.co.uk A design pattern ontology would be a very different thing to an ontology design pattern, but both are things of value. At the Object Management Group (OMG) we maintain a suite of standards based on many of these design patterns, i.e. UML and the underpinnings in MOF. We are also exploring whether or how to move some of these modeling languages from being MOF-based to using the new more semantically rich framework that has been developed for the SysML V2 standards (which has a kernel language called KerML). These are still in the Finalization process. This is where the distinction between model semantics and the semantics of the target problem domain subject matter become an important consideration. For example MOF was all about model element semantics. Ideally some of these directions will move things towards something with clear formal semantics both for model semantics and how subject matter semantics is treated. Whether that's in KerML or a more conventional ontology standard such as FOL or DL, or a syntax such as RDF/OWL, remains to be seen. If anyone did happen to be doing a formal ontology of these software design patterns, this would be very helpful to know. Meanwhile you should probably also check out the OMG's ESSENCE standard (spearheaded by Ivar Jacobson) for the kind of model concepts needed to model a design methodology. Mike On 11/25/2024 7:41 PM, 'Igor Toujilov' via ontolog-forum wrote: