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). odSystems.owl is the module describing functionalities, both at the social and at the computational levels. These functionalities are not those of an ontology (its 'task'), but those of the design of an ontology. 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 systems ontology 41 'Rich' functionality descriptions, in which roles, goals, parameters over roles and tasks, and complex tasks are put together to compose a 'method', e.g. a method to execute ontology selection, versioning, subclass addition, expressing disagreement, etc. There is an analogy to the parametric design paradigm (Motta, 1999), where so-called 'tasks' are analogous to functionality descriptions, while 'problem-solving methods' are analogous to functionality methods. Besides this distinction, it's possible to distinguish between social functionality descriptions/methods, and computational ones. Analogously, in software engineering computational functionality descriptions are called 'requirements' or 'use cases', while computational functionality methods are called 'specifications'. The difference between social and computational level is clearer on the specification (methods) side. An action involving computational objects and accomplishing a functionality defined in a software specification. 'Poor' functionality descriptions, in which, besides a generic goal and possible roles, only the main task (functionality) to be accomplished is indicated, e.g.: ontology selection, ontology versioning, adding a subclass, disagreeing on a choice, etc. Generic functionality descriptions are analogous to requirements, use cases, and parametric design' tasks. A functionality to be implemented in a programming language. A functionality is considered here a task to be performed within an ontology project, e.g. an 'evaluation' functionality. As any other task, functionalities are 'defined-in' some description/schema, in this case in some 'functionality description'. Once defined, functionalities become available to be used-in a certain ontology project (schema). A plan that defines a certain functionality (a type of edns:task). Functionality descriptions can be of two types. The first includes 'poor' functionality descriptions, in which, besides a generic goal and possible roles, only the main task (functionality) to be accomplished is indicated, e.g.: ontology selection, ontology versioning, adding a subclass, disagreeing on a choice, etc. The second type includes 'rich' functionality descriptions, in which roles, goals, parameters over roles and tasks, and complex tasks are put together to compose a 'method', e.g. a method to execute ontology selection, versioning, subclass addition, expressing disagreement, etc. There is an analogy to the parametric design paradigm (Motta, 1999), where so-called 'tasks' are analogous to functionality descriptions, while 'problem-solving methods' are analogous to functionality methods. Besides this distinction, it's possible to distinguish between social functionality descriptions/methods, and computational ones. Analogously, in software engineering computational functionality descriptions are called 'requirements' or 'use cases', while computational functionality methods are called 'specifications'. A description of a functionality to be implemented in a programming language or an architectural paradigm, e.g. an algorithm. Software specifications characterize 'computational functionalities' that are expected to be accomplished by running a computational operation. A software specification only characterizes computational functionalities, because social, e.g. human-based, functionalities are 'simulated' in two ways: by 'substituting' social roles with computational roles; by 'supporting' social roles, which only appear as proxy roles. See also Daniel Oberle's 'Semantic Middleware'. Social method specification It's possible to distinguish between social functionality descriptions/methods, and computational ones. Analogously, in software engineering computational functionality descriptions are called 'requirements' or 'use cases', while computational functionality methods are called 'specifications'. The difference between social and computational level is clearer on the specification (methods) side.