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). odRationales.owl is the module that describes how to encode the motivations behind a design solution, so that they can be made explicit (choice space), argumented, and finally attached to an agreed solution. 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. ontology design rationales ontology 41 Rationales could be of different sorts, and a specific rationale can result as a composition of those sorts. Ontology design can be motivated with reference to task or sustainability criteria, but it is typically motivated with reference to structure and content, i.e. against a choice space created by the use of a pattern (either implicit or explicit) and a rationale that motivates its application. We call these rationales 'content rationales'. For example, if a designer is designing an ontology from a flat list of 10 classes, and is willing to apply the subClassOf axiom pattern to a class Dog against those 10 classes, the implicit choice space has a cardinality=10 (9 possible superclasses, or being a top class). If the rationale of choosing e.g. the axiom Dog subClassOf Canine is that Dog's instances are all Canine's instances, the designer is applying an 'extensional semantics' rationale to the pattern employed. In other words, the design pattern (in the example, the subClassOf axiom pattern) represents the design quality of a certain design solution (in the example, the actual axiom), whose rationale is 'extensional semantics', and whose rationale application is the design choice of the Dog subClassOf Canine axiom because all Dog's instances are also Canine's instances. Of course, the choice can be motivated by different rationales, e.g. the axiom Dog subClassOf Canine can be supported by a 'lexical semantics' rationale, which could take WordNet hyponymy relation as evidence. Another rationale is the 'expertise semantics' rationale, which could use a poll system against a sample of domain experts voting on the best candidate as Dog's superclass. Still another rationale is 'best approximation semantics' to a repository of content design patterns, so that the best candidate as a superclass may be chosen from an existing content pattern that includes Dog and Canine, with a best similarity match. Arbitrarily complex rationales can be built to support decision on simple patterns like subClassOf or very complex ones like content pattern composition. As another, more complex example, a choice can involve two different patterns. E.g. a designer wants to create a relation between A and B, but she is undecided if the relation is A subClassOf B or A partOf B. The two possible choices are not two axioms, but two different axiom patterns, which have their own related choice spaces. The choice space of the designer is the union of those choice spaces, while the rationale is some combination of the rationales pertaining to the different choices. In practice, the designer can apply: - an extensional rationale to A subClassOf B: the relative choice space has a cardinality of 4: either all A's instances are all B's instances, or not all, or none (disjointness), or unknown, and - an 'intensional' rationale to A partOf B: the relative choice space has a cardinality of 4: either it is conceivable in the designer's world to think of all A's instances as being part of some B's instance, or it is conceivable in the designer's world for any A's instance to be part of any B's instance, or no A's instance can ever be part of any B's instance, or it is unknown. The combined rationale is executed against a choice space with a cardinality of 4*4=16, i.e. any combination of one choice from the first set and one choice from the second set: first set: either A subClassOf B, or A overlaps B, or A disjoint B, or unknown(A subClassOf B), and second set: A partOf some B, or A partOf only B, or A partOf exactly 0 B, or unknown(A partOf B). Choice spaces are defined here as collections of choice spaces, i.e. possible situations resulting from the application of a rationale to one or more design pattern, either architectural (untyped, see the class: architectural-design-pattern), or content (typed, see the class: content-design-pattern). Rationales could be of different sorts, and a specific rationale can result as a composition of those sorts. Sustainability rationales are pragmatic principles that motivate a choice. For example, the cost of a design solution, measured in hours, money, computational complexity, etc., is a typical sustainability rationale. Another one is provenance, by which authoritativeness of a solution is advocated for reuse. A description of the motivations behind ontology design choices, involving design operations, ontology elements, and rational agents (the designers). Although design choices involve operations to materialize a design, we would like to distinguish between design choices concerning the 'structure' of ontologies versus choices concerning their production, implementation, etc. The first set of choices will be represented with reference to so-called 'ontology design patterns', while the second set will be represented with reference to 'lifecycle design patterns'. The first set is the main focus in the current version of this ontology, while the second will be possibly considered in future work. Note that this ontology currently includes the representation of production and implementation of ontologies, but not (explicitly) the representation of their design choices (i.e. those related to 'lifecycle design patterns'). Ontology design can be motivated with reference to task or sustainability criteria (see below), but it is typically motivated with reference to structure and content, i.e. against a choice space created by the use of a pattern (either implicit or explicit) and a rationale that motivates its application. For example, if a designer is designing an ontology from a flat list of 10 classes, including {Dog, Canine, ...}, and is willing to apply the subClassOf axiom pattern to Dog, the implicit choice space has a cardinality=10 (9 possible superclasses, or being a top class). If the rationale of choosing e.g. the axiom Dog subClassOf Canine is that Dog's instances are all Canine's instances, the designer is applying an 'extensional semantics' rationale to the pattern employed. In other words, the design pattern (in the example, the subClassOf axiom pattern) represents the quality of a certain solution (in the example, the actual axiom), whose rationale is 'extensional semantics', and whose rationale application is the design choice of the 'Dog subClassOf Canine' axiom, because all Dog's instances are also Canine's instances. As a matter of fact, the choice can be motivated by different rationales, e.g. the axiom Dog subClassOf Canine can be supported by a 'lexical semantics' rationale, which could take WordNet hyponymy relation as evidence. Another rationale is the 'expertise semantics' rationale, which could use a poll system against a sample of domain experts voting on the best candidate as Dog's superclass. Still another rationale is 'best approximation semantics' to a repository of content design patterns, so that the best candidate as a superclass may be chosen from an existing content pattern that includes Dog and Canine, with a best similarity match. Arbitrarily complex rationales can be built to support decision on simple patterns like subClassOf, as well as on very complex ones, like content pattern composition. As another, more complex example, a choice can involve two different patterns. E.g. a designer wants to create a relation between A and B, but she is undecided if the relation is A subClassOf B or A partOf B. The two possible choices are not two axioms, but two different axiom patterns, which have their own related choice spaces. The choice space of the designer is the union of those choice spaces, while the rationale is some combination of the rationales pertaining to the different choices. In practice, the designer can apply: - an extensional rationale to A subClassOf B: the relative choice space has a cardinality of 4: either all A's instances are all B's instances, or not all, or none (disjointness), or unknown, and - an 'intensional' rationale to A partOf B: the relative choice space has also a cardinality of 4: either it is conceivable in the designer's world to think of all A's instances as being part of some B's instance, or it is conceivable in the designer's world for any A's instance to be part of any B's instance, or no A's instance can ever be part of any B's instance, or it is unknown. The combined rationale is executed against a choice space with a cardinality of 4*4=16, i.e. any combination of one choice from the first set and one choice from the second set. The first set: either A subClassOf B, or A overlaps B, or A disjoint B, or unknown(A subClassOf B), and the second set: A partOf some B, or A partOf only B, or A partOf exactly 0 B, or unknown(A partOf B). Choice spaces are defined here as collections of design choices, i.e. possible situations resulting from the application of a rationale to one or more design pattern, either architectural (untyped, see the class: architectural-design-pattern), or content (typed, see the class: content-design-pattern). Rationales could be of different sorts, and a specific rationale can result as a composition of those sorts. A first sort, content rationales, are usually data, like attributes, measurement data, natural language evidence, etc., which motivate a choice within a choice space for a design operation. Content rationales have been exemplified above. A second sort is task rationales, usually queries (also called competency questions) that motivate a choice within a choice space for a design operation. Motivating queries can be represented as use case descriptions, and can be exploited as unit tests. Task rationales usually address complex choices, because they are matched to clusters of design solutions that can satisfy a competency question. Task rationales can be used at best together with a 'best approximation semantics' rationale, i.e. together with a repository of content design patterns (the repository can be either existing, or created on the fly). A third sort is sustainability rationales, usually pragmatic principles that motivate a choice. For example, the cost of a design solution, measured in hours, money, computational complexity, etc., is a typical sustainability rationale. Another one is provenance, by which authoritativeness of a solution is advocated for reuse. Here: a description of the motivations behind design making, involving design operations, components, and rational agents (the designers). Rationales could be of different sorts, and a specific rationale can result as a composition of those sorts. Task rationales are usually queries (also called competency questions) that motivate a choice within a choice space for a design operation. Motivating queries can be represented as use case descriptions, and can be exploited as unit tests. Task rationales usually address complex choices, because they are matched to clusters of design solutions that can satisfy a competency question. Task rationales can be used at best together with a 'best approximation semantics' rationale, i.e. together with a repository of content design patterns (the repository can be either existing, or created on the fly).