The issue of powertypes appears on both system and conceptual perspectives: to translate requirements into models, and to weave concepts into the fabric of models. If their use is to be consistent and neutral across perspectives, powertypes should be defined uniformly, independently of the semantics of targeted elements.
Powertypes & the Modeling of Systems
Partitions & Powertypes
Starting with the modeling of systems, powertypes should be defined with regard to partitions and representations; with regard to partitions:
- Structural partitions are set once and for all; e.g., wines’ grape or poultry type.
- Phased partitions are nonstructural, with changes subject to events and sequencing constraints; e.g., the shelf-life of food products.
- Functional partitions reflect the roles of targeted objects; e.g., how food products are employed in diet or gourmet dishes.
- Analytical partitions are nonstructural ones defined on the value of individual features (data) independently of states and roles; e.g., wines’ customers’ segments.
Yet, as far as systems models are concerned, partitions are not necessarily represented by powertypes:
- Partitions can be simply represented by attributes when no additional features have to be managed.
- Powertypes are introduced when partitioned subsets are associated with shared values. In that case powertypes instances are used to manage the shared features. For example, wine categories combining grape, region, and age can be matched with dishes.
- In contrast to powertypes, delegation introduces functional types to support the instantiation of phases or roles. For example: cooking states (phases) or the contextual pricing of dishes depending of menus (roles).
- Subtypes are needed when variants are not limited to the valuation of aspects (as with delegation), but induce different aspects; For example alcoholic and non-alcoholic beverages.
As represented with OWL:
It ensues that deciding on representation, and consequently defining powertypes with regard to subtypes, depends on the semantics of powertypes instances.
Instances & Individuals
As illustrated by UML’s ambiguous position, the semantics of instances in modeling languages don’t make a difference between individuals identified outside systems and surrogates managed inside. As a corollary, representation issues, i.e., the mapping of extensional (physical and business environments) and intensional (systems) models, are ignored by both systems and conceptual perspectives. Powertypes can be used to span the overlooked no man’s land.
The first step is to draw the line between powertypes, to be defined, and subtypes, whose semantics are clearly defined by systems modeling languages. To that effect, instances of powertypes should not be confused with instances of types, or be understood as subtypes.
Taking wines as example, instances of powertypes for grapes (Merlot, Cabernet, …) and regions (Tuscany, California,…) can neither be understood as wines, or as subtypes that could be instantiated as wines.
Alternatives interpretations vary between universals, patterns, or embodiments:
- Universals: powertypes stand for sets of logic predicates meant to be applied to concepts; e.g., alcohol levels
- Profiles: powertypes are seen as functional descriptions; e.g, dessert wines
- Embodiments: powertypes represent virtual collectives of structurally related instances; e.g., some great wines are identified by very specific mixes of grapes and territories
Besides overlaps, each of these interpretations raises typical issues:
- Instances of powertypes as universals should be identified lest they couldn’t be referred to. For example, alcohol levels should be associated with regulations.
- Powertypes as profiles may be confused with patterns or abstract types.
- Instances of powertypes defined as embodiments may induce mixed semantics with individuals. For example Masseto and Chateau Latour instances can be understood as wine or kinds of wine.
To overcome these issues powertypes should be seen as filters between modeling types and instances, which implies that:
- They are symbolic objects, but cannot be used to create instances. In other words they are types (extensional constructs) but cannot be seen as classes (intensional constructs)
- Instances of powertypes must be identified on their own so they can be referred by instances of other types
- Powertypes are not prototypes, i.e., instances are used to index individuals identified separately
These guidelines put the focus on the semantics of instances and the explicit distinction between their nature (symbolic or physical) and identity principle (social, biological, designed). That distinction becomes critical for conceptual powertypes.
Powertypes & Ontologies
Ontologies combine models and thesaurus: the former with categories (or types) representing instances of objects or phenomena, the latter with concepts defining the semantics of the terms employed, independently of their use by categories. To remain consistent and neutral, powertypes in conceptual models should be defined directly in terms of instances and partitions, independently of categories or types.
System & Conceptual Powertypes
Thinking is all about making distinctions, which can be done along three basic perspectives: analysis (making sense of environments), design (building symbolic or actual artifacts), or communication (sharing the meanings ). Categories can be directly applied to analysis (types) and design (classes), but concepts are meant to serve a more general communication purpose. To that end, and to ensure consistency, conceptual powertypes should maintain and generalize the system modeling distinction between observed (extensions) and designed (intensions) instances.
For example:
- Food, beverage, and cooking are commonly used concepts with broadly defined semantics and classifications represented as powertypes, e.g., food groups.
- Meat, cereals, cheese, and cooking are categories that can be defined differently depending on contexts and purposes.
- Observed instances can be identified independently of categories or concepts before being associated with any number of them.
- Designed instances are symbolic (e.g., menu, recipe) or actual ones (oven, omelette) objects or procedures. As such they are rooted to some initial symbolic category.
- Since powertypes can be introduced from both concepts and categories, their use with regard to the type of instances must be aligned.
That twofold distinction between intensions and extensions marks also an engineering pivot for:
- Systems engineers, between business requirements and architecture capabilities
- Knowledge engineers, between environments and conceptual representations
While the perspectives are best carried out separately, they will often overlap, and that’s where conceptual powertypes are to help. For example, food industries have to manage physical (actual products), business (e.g., recipes and processes), and scientific (e.g., nutrients) representations. Since the semantics of classification are arguably different in physical, business, and scientific domains, jumbling powertypes will hamper the interoperability of representations. Surprisingly, that issue is usually ignored by conceptual modeling approaches, and more generally ontological ones.
The Matter of Conceptual Instances
Conceptual models are meant to organize the representation of instances of objects and phenomena, the former characterized by a perennial identity (hence the names of endurants, perdurants, or continuants), the latter by a time-related identity (moments, events, or processes).
A critical assumption is then made with regard to the basic kinds of perennial instances: one for intrinsic identity, one for roles, and one for phases. As a corollary, perennial instances are supposed to be either physical, or are understood in terms of roles: there is no conceptual room for symbolic objects identified on their own, and consequently for business entities (e.g., parties, contracts) which must be coerced into roles or relationships. Powertypes provide a solution.
To begin with, the principle of identity must be refined as to take into account the epistemic distinction between physical, social, and scientific realms.
Then, powertypes are introduced to mark the commons and ensure conceptual interoperability. For example:
- Concepts for food and nutrients (a)
- Powertype for good groups (b)
- Enterprise architecture pattern for products’ references (c)
- Business category with physical instances for inventories (d)
As a concluding remark, the significance of the restricting assumption goes beyond the remit of modeling as it implies that concepts can be unambiguously attached to clearly identified physical objects or phenomena. Such an assumption goes against the very purpose of ontologies which is to detail the epistemic nature of “things”.