The instantiation of a design rationale in the design of an ontology. A design making is a setting for at least the following entities that play roles in the rationale: a rational agent, one or more information objects, a design operation on them, and a time interval at which the operation occurs. A design making satisfies both a design rationale (its context), and a functionality description (its method). A skin is a schema for purely 'structural' design patterns, i.e. description of the elements to be put into an ontology that is supposed to reuse an architectural or content design pattern. For example, a skin for the subClassOf pattern will be defined with one role that classifies only a subsumption relation, and two roles for classes in that partial order. A skin for a partOf pattern will be defined e.g. with one role for a mereological relation, and three roles for two entities of a same category (e.g. either objects or events), and one role for a time interval. Cloning is different from (local) importing, because it changes the namespace of the imported expression, typically in order to modify the characterization of that expression. For the same reason, a clone is also different from a module: once cloned, e.g. a content design pattern has a unity and identity independent from the ontologies where the elements have been taken from. The range of cloning is 'configuration' and not 'network of ontologies', because cloning typically acts on fragments of networked ontologies, while networks of ontologies are taken as wholes. Anyway, we might say that e.g. a cloned ontology is 'extracted' from a network of ontologies. Architectural design patterns are untyped ontology design patterns. An untyped design pattern is a formal expression, whose only parts are expressions from the logical vocabulary of a theory. Architectural patterns have only logical design patterns as parts, and (differently from logical design patterns), are intended to be applied to an ontology as a whole. Typical architectural design patterns are complex global production patterns, like the famous Aristotelian 'genus et differentia specifica' for building taxonomies with explicit, incremental criteria. Other architectural patterns include: 'matricial' (based on specific values that distinguish the application of properties to different classes), 'free-style' (creating axioms first, then trying to organize them into ordered sets), 'descriptive' (creating two-layered models for making sense of reification and/or meta-modelling), 'split existential' (splitting the complexity of reasoning with existential restrictions between two-layered models), etc. A clone of a configuration of ontology elements, usually (but not necessarily) from a same reference ontology. A CODeP is a typed design pattern, because it is a clone of a collection of ontology elements that have a 'type', i.e. a name from the non-logical vocabulary of a theory. Content design patterns 'specialize' architectural patterns: this means that content introduces a vocabulary to existing structure, e.g. logical constructs. CODeP A structural situation (state) that includes only formal expressions (at least one content design pattern), and their relations. For example, the occurrence of a subClassOf axiom (which is an ontology element) and its elements, as included in a design solution complying to a subClassOf OWL macro. omv:Ontology A sequence expressing the steps to perform an inference. The description of a design pattern includes the roles, tasks, and parameters needed in order to implement a 'best' practice for an ontology design choice. For example, a DPS for content creation provides instructions to clone, choose, compose, or specialize an existing ontology or collection of ontology elements, possibly according to 'best practices'. Structural patterns have simpler, non-procedural descriptions, which are called here 'skins'. 41 ontology design solutions ontology The C-ODO library currently contains 8 native ontologies, and imports or uses several others, either for design purposes (DOLCE, cDnS, etc.), or for extending their scope (owlodm, OMV, oQual, SKOS, NeOn networked ontology model). odSolutions.owl is the most specific module of the library, and it inherits all others (but not the aligned ontologies like OMV and owl1.0). It allows to talk specifically of design solutions, i.e. states of a networked ontology that include the ontology elements (see odData.owl) that have been agreed (see odArgumentation.owl) within a certain procedure (see odWorkflows.owl) carried out in a project (see odProjects.owl), for some reason (see odRationales.owl). C-ODO is an ontology for ontology design, to be used as a set of social requirements for NeOn methodologies and tools. The key notion is 'ontology project', which is assumed to be made up of knowledge-level ('epistemic') workflows, which on their turn contain 'argumentation structures' and 'design rationales' that motivate 'design solutions' taken from a 'choice space' generated by 'design patterns' over 'ontology elements'. Appropriate roles (e.g. 'knowledge product', 'knowledge creator') and tasks (e.g. functionalities like 'selection', 'importing', etc.) are used by project, workflow, and rationale schemas. Situation classes ('ontology project execution', 'epistemic workflow enactment', 'argumentation situation', 'design making', 'design solution') are introduced in order to reason on the actual occurrences of those schemas. Moreover, ontology objects and other information objects used during the ontology lifecycle, together with the design operations and the designer agents, are framed by those situations if they comply to the roles and tasks used by the schemas. Types of projects, workflows, argumentation, rationales, patterns, etc. are also introduced in C-ODO. The schema-situation approach is an architectural design pattern that is wholly axiomatized in the cDnS ontology (http://www.loa-cnr.it/ontologies/cDnS.owl). It allows to talk of contexts (or methods, plans, etc.) in the same domain as the actual situations (executions, observations, etc.) that exemplify those contexts. More generally, the ontology design ontology uses the following patterns: - the DnS content pattern (http://www.loa-cnr.it/ontologies/ExtendedDnS.owl) has been used throughout, and the following sub-patterns have been used: a) descriptions and concepts depend on existential axioms only when they involve 'descriptive' entities b) descriptions are constrained wrt a given situation class SC c) concepts are constrained wrt a given entity class EC d) SC are defined by requiring that some entity from EC is in their setting. - the collections pattern (http://www.loa-cnr.it/ontologies/ExtendedDnS.owl), and the following sub-patterns have been used: a) collections have any entities as members b) collections are covered or characterized by concepts c) collections are unified by descriptions that use or define those concepts. -the plans pattern (http://www.loa-cnr.it/ontologies/Plans.owl): a) plans use tasks, roles, and parameters b) plans have a main goal as a proper part c) plans are 'executed' within plan executions by agents playing roles in order to perform the tasks used by the plan d) plan executions start from certain situations ('preconditions') and result in certain situations ('postconditions'). Postconditions can be compliant or not to the expected goal. 1 OWL macros are composed logical design patterns for the OWL language. An OWL macro provides a unity criterion to a set of ontology constructs that are then expanded by OWL parsers and reasoners. Any (composed) design pattern within the OWL expressivity can be reduced to a macro. A class for holding together different kinds of solutions to ontology design. E.g. 'bipartite graph', 'acyclic graph', Porphyrean tree, two-layered modelling, etc. A formal encoding of a use case. It can either be generic or specific, i.e. bound to a certain domain. Competency questions are typical use cases. A unit test is any formal expression that can be used (e.g. adding a pattern, submitting a query, etc.) to an existing ontology, in order to measure its fitness to some task. Unit tests are closely related to 'qoods' and especially to design pattern schemas. Logical design patterns are untyped ontology design patterns. An untyped design pattern is a formal expression, whose only parts are expressions from the logical vocabulary of a theory. Logical design patterns can be simple, like elementary constructs in e.g. OWL, or complex, i.e. compositions of elementary ones. A choice space is the collection of 'possible' design choices that are allowed when applying a 'structural' design pattern to an ontology design problem. Typically, a design rationale motivates a choice decision wrt a choice space by filling one or more parameters used by the rationale. An action carried out to accomplish some 'functionality', according to the method represented by a 'functionality description'. Design operations are the prominent entities in a 'design choice' situation. In the requirement-specification-implementation cycle, ideally, each design operation should be performed, assisted, or proxied by a computational operation.