37 ontology design ontology 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 choices' 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 choice') 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. 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. An OWL macro provides a unity criterion to a set of ontology constructs that are then expanded by OWL parsers and reasoners. Any design pattern within the OWL expressivity can be reduced to a macro. 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 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 collection whose members are 'unified', i.e. organized according to a certain schema that can be represented by a description. Typically, a configuration is the collection that emerges out of an composed entity: an industrial artifact, a plan, a discourse, etc. E.g. a physical book has a configuration provided by the part-whole schema that holds together its cover, pages, ink. That schema, based on the individual relations between the book and its parts, can be represented in a reified way by means of a (structural) description, which is said to 'unify' the book configuration. From the Plan Ontology: http://www.loa-cnr.it/ontologies/Plans.owl. We are proposing here a restrictive notion of goal that relies upon its desirability by some agent, which does not necessarily play a role in the execution of the plan the goal is a part of. The minimal constraint for a goal is that it is a proper part of a plan. For example, a desire to start a relationship can become a goal if someone takes action (or lets someone else take it for her sake) to obtain it. Any project aiming at entering the lifecycle of an ontology. As all projects, ontology projects inherit the characteristics and constraints typical of projects: teams, persons, schedules, time, funding, strategical considerations, etc. An individual ontology choice, e.g. adding a class, is not a project per se, although it can be viewed from that perspective, if the only objective of a project is to produce that change into the ontology. ontology project An execution of a certain ontology project (schema). Execution can be more or less constrained according to the constraints, preferences, and resources declared in the project (schema). 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. A generalized formal construct asserting relations between classes, e.g. rdfs:subClassOf assertions, owl:restrictions, domain and range restrictions, equivalences, etc. An enactment for an e-collaboration workflow. It is the setting for at least two rational agents, both accountable. A schema or frame for argumentation primitives, e.g. agree/disagree, motivated claim, etc. An argumentation structure for ontology design is supposed to include a rationale that is used to argue about a design choice. 2 From the D&S ontology: http://www.loa-cnr.it/ontologies/ExtendedDnS.owl. Collections are social objects which depend both on member entities and on some concepts, hence they indirectly depend on descriptions. We can talk of collections of any kind of entities (events, objects, abstracts, etc.). 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). From the D&S ontology: http://www.loa-cnr.it/ontologies/ExtendedDnS.owl. A concept classifying only objects. An argumentation task is a complex task to be accomplished within an argumentation situation. Four typical classes of argumentation tasks have been singled out: choice-confrontation, rationale-declaration, dialectic-rule, argument-resolution. A class whose elements are classes. A co-participation between two agents. A knowledge role taken by information objects produced through an epistemic workflow. 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. A collection of categories organized according to a specified syntax, typically used to create a controlled terminology in a domain. A useful owl encoding of a typical thesaurus syntax is the SKOS schema (). 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 event. ontology lifecycle Any occurrence of the ontology lifecycle schema (http://www.loa-cnr.it/ontologies/OD/OntologyDesign.owl#ontology-lifecycle-schema) characterized in this ontology. An e-usage is an epistemic workflow that uses two additional roles: accountable performer (for agents that adopt the main goal), and non-accountable information creator (for agents that have created the information resource to be used in the workflow, without being actively involved in the knowledge creation plan). More details are contained in the corresponding class: e-usage-situation. An e-collaboration is a case of epistemic workflow that prescribes the proactive involvement of all rational agents, i.e. all the involved rational agents adopt the main goal of the e-collaboration. A rational agent can also be a team, provided that the members perform actions expected by a shared e-interaction plan. More details are contained in the corresponding class: e-collaboration-situation. 1 4 A situation with at least two objects participating in a same event. ontology Here: a (usually complex) typed formal expression, which can be realized either analogically or as a non-executable digital object. An ontology is a typed theory, i.e. its characteristic elements are named after a non-logical vocabulary. A collaboration workflow focused on arguing on one or more design choices. As inspired by van Eemeren and Grootendorst (2004), an argumentation session includes four complext task types: choice-confrontation, rationale-declaration, dialectic-rule, argument-resolution. Argumentation rules can be composed of any set of tasks defined in an argumentation-structure. From the Information Objects ontology: http://www.loa-cnr.it/ontologies/InformationObjects.owl. The realization of an information objects in some physical entity. An ontology network whose unifying relation has no semantic consequence on the internal structure of networked ontologies. Relations such as identity, equivalence, versioning, etc. create simple ontology networks. A practical consequence is that E-Connection semantics does not make it emerge a distributed ontology from the networked ontologies. A performer role that is not accountable within the plan that uses the role. A role played by entities within a post-condition of a (production) plan. 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. 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. A collection of tags or metadata that have no formal semantics, and are typically used sparsely to annotate texts, images, bookmarks, etc. QOOD is an acronym for 'Quality-Oriented Ontology Description', and has been defined in Gangemi et al. ESWC06. The reused ontology is at: http://www.loa-cnr.it/ontologies/EVAL/oqual.owl. QOODs are descriptions of what is needed in an ontology and in its use case to be appropriate to some criterion. QOOds are therefore useful for ontology design and specially for evaluation and selection. Design pattern schemas are considered here special cases of QOODs, and can also be used to implement unit tests for existing ontologies. Here: a description of the motivations behind design making, involving design operations, components, and rational agents (the designers). 1 Information can be considered knowledge when it is possible to reason on it, e.g. by inferring new information from the existing one. Reasoning can be performed by humans, but some forms of inference can be performed by machines. In this ontology, we abstract from the distinction between human and automatic reasoning, because ontology lifecycle includes both. A knowledge role here is played by information objects when they are managed within an epistemic influence situation. Knowledge roles are distinguished into 'resources', 'working items', and 'products'. Those distinctions follows the input-throughput-output pattern from open systems. An (identified) element from an ontology. Classes defined under ontology elements should be mapped to either OMV classes or to Ontolingua's FrameOntology. From the Plan Ontology: http://www.loa-cnr.it/ontologies/Plans.owl. A plan is a method for executing or performing a procedure or a stage of a procedure. A plan must use both at least one role played by an agent, and at least one task. Finally, a plan has a goal as proper part, and can also have regulations and other descriptions as proper parts. A performerRole that is superordinated to knowledge roles, e.g. a knowledge product role depends on the knowledge creator role. A performer role that is only played by rational agents that adopt the main goal of the plan using the role. A network of ontologies (or ontology network) is a collection of ontologies with a specified unifying criterion (description), provided by (reifying a) relation such as 'being a version of', 'imports', 'identical to', 'equivalent to', 'is clone of', 'mapped to', 'contains module', etc. Network of ontologies 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'. From the D&S ontology: http://www.loa-cnr.it/ontologies/ExtendedDnS.owl. A situation is a social object that appears in the domain of an ontology only because there is a description whose components can 'carve up' a view (setting) on that domain. A situation has to 'satisfy' a description, and it has to be 'setting for' at least one entity. In other words, it is the ontological counterpart (with due local differences or restrictions) of settings (situations from Situation Calculus, formal contexts, episodes, states of affairs, structures, configurations, cases, etc.). Two descriptions of a same situation are possible. The time and space (and possibly other values) of a situation are the time and space of the events and objects occurring in the setting. Any relationship between rational agents that influences the knowledge of one or more agents in the relationship, according to a workflow shared by one or more or even all the agents. An epistemic workflow is both an epistemic influence and a plan, whose main goal is knowledge production. At least one 'accountable performer role' is used by all epistemic workflow. An ontology network whose unifying relation has semantic consequences on the internal structure of networked ontologies. Relations such as merging, aligning, importing, etc. create qualified ontology networks. A practical consequence is that E-Connection semantics can make it emerge a distributed ontology from the networked ontologies. Issue to be clarified: should a distributed ontology be identical to the ontology network it emerges from, or not? While in cases like importing and merging that seems reasonable, in other cases like mapping, aligning, reusing, etc., that is possibly inadequate. Another solution is to keep networks and ontologies separate, and advocating an extensional equivalence when all the elements of ontologies in a qualified ontology network are also element of a distributed ontology. 5 A situation satisfying an epistemic influence description. From the D&S ontology: http://www.loa-cnr.it/ontologies/ExtendedDnS.owl. A concept classifying only actions. An enactment for an e-interaction workflow. It is the setting for at least two rational agents: one an accountable performer, the other a non-accountable performer. A role played by entities during the execution of a plan, which do not play at the same time any performer or product roles. A relationship between rational agents that influences the knowledge of one or more agents in the relationship. The relationship uses at least the two roles: agent-driven-role, and informationResource. There can be only one rational agent that is 'influenced' by some information produced at a different time by the same agent. From the D&S ontology: http://www.loa-cnr.it/ontologies/ExtendedDnS.owl. A description is a social object which represents a conceptualization (e.g. a mental object or state), hence it is dependent on some agent and communicable. Descriptions can also be taken as reifications of 'cognitive' contexts or logical n-ary relations. Descriptions 'use' concepts, are 'expressed by' information objects and can be 'satisfied by' situations. 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. A knowledge creator role that is not an accountable performer role. From the Information Objects Ontology: http://www.loa-cnr.it/ontologies/InformationObjects.owl. Information objects are social objects. They are realized by some entity. They are encoded within some system for information encoding. Consequently, they are dependent from an encoding as well as from a concrete realization. They can express a description (the ontological equivalent of a meaning/conceptualization). They can be about any entity. They can be interpreted by an agent. From a communication perspective, an information object can play the role of 'message'. From a semiotic perspective, it plays the role of 'expression'. Any one of the OWL species, currently one of: lite, dl, and full 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). '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. A knowledge creator role that is also an accountable performer role. A resource role played only by information objects. A knowledge role taken by information objects used as resources through an epistemic workflow. '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 design operation involving computational objects and accomplishing a functionality defined in a software specification. E.g. 'bipartite graph', 'acyclic graph', Porphyrean tree, two-layered modelling, etc. A role played only by rational agents. An enactment for an e-usage workflow. It is the setting for at least two rational agents: one accountable, the other a non-accountable knowledge creator. A formal construct with a semantics similar to classes, but without an explicit naming. E.g. OWL 'restrictions'. Unnamed classes are both classes and axioms. An ontology repository. An ontology that is member of an ontology network. In practice, an ontology is networked when it has some relation to other ontologies. An ontology can be networked because it started a relation after its creation, or because it emerges from a (qualified) relation between other ontologies, as in the case of qualified ontology networks. In the second case, it can be called a 'inherently networked' ontology. For example, two ontologies O1 and O2 that have an equivalence relation, are networked ontologies. More interestingly, an ontology O3 that has been designed by reusing components from two ontologies O4 and O5 is a distributed ontology. The goal of producing knowledge. From the D&S ontology: http://www.loa-cnr.it/ontologies/ExtendedDnS.owl. A social object that is used by a description s, and whose function is classifying entities from a ground ontology in order to represent situations that can satisfy s. Concepts can be considered as the reification of unary predicates or relation domains, or roles in either conceptual modelling or description logics. 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 can be either very simple, such as OWL macros (cf. Vrandecic 2005), or complex global production pattern. Among complex architectural patterns, the famous Aristotelian 'genus et differentia specifica' for building taxonomies with explicit, incremental criteria, is an architectural pattern. Other architectural patterns are: '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. 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). 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 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. 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'. 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). An e-interaction is a case of epistemological influence that prescribes the proactive involvement of two rational agents. One rational agent can also be a team, provided that the members perform actions expected by a shared e-interaction plan. Moreover, only some of the activated rational agents adopt the goal of the e-interaction (some are non-accountable). More details are contained in the corresponding class: e-interaction-situation. A role played by entities when are temporary states of an expected final product. 1 A role taken within an argumentation situation, e.g. an axiom that is 'motivated' or 'agreed upon' within a design making. 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 knowledge collective is a community that is characterized by some practices of knowledge communization. In this ontology, this is formalized as being a 'collective' that is 'unified by' some 'epistemic workflow'. An agent-driven role that is only played by rational agents that (actively) participate in some action at the time of role-playing. The enactment of an epistemic workflow. 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. Each plan has one main goal. Local name for edns:d-used-in. An agent argues about a design choice (situation) or about an information object that is implemented or used in ontology design. It could be assumed that in case an agent argues about an ontology element, she is actually arguing about a design choice. This property is typically asserted within an argumentation situation. Local name for edns:d-uses. A partial order relation that holds between descriptions. It represents the proper part relation between a description and another description featuring the same properties as the former, with at least an additional one. Descriptions can be expanded either by adding other descriptions as parts, or by refining concepts that are used by them. An 'intention' to expand must be present (unless purely formal theories are considered, but even in this case a criterion of relevance is usually active). Any relation between two (networked) ontologies.