COMMONS14 — Need a core ontology for parthood/mereology separate from Collections

Summary

Parthood is a foundational subject and we're lacking even partially-complete coverage in OMG to form the basis of other specifications or customer ontologies.
Mereology has a lot of potential aspects, only a minority of which are related to Collections, which is where the support we have is squirreled away (and hard to find). Even what we currently have there has little to do with collections: organizational sub-units, geographic subregions, and components of compositions.
This issue proposes moving the whole-part relations into a small, separate Commons ontology (working name Parthood) that Collections and other modules import. The new module would also give Commons a home for alignment with the part-whole relations in OntoUML, which is on track to become an OMG specification.

This issue is related to COMMONS-26, which fixes inconsistencies in the current Collections parthood and membership properties. Those fixes should not wait for this one.

Motivation

1. Parthood is a general topic. hasPart / isPartOf sit in Collections because of the ontology's origins in LCC, not because they relate to collections. cmns-org:hasSubUnit and cmns-loc:hasSubregion are sub-properties of hasPart and have no connection to collections.
2. Defining parthood and membership together has caused confusion. Several problems raised in COMMONS-XX come from this: the Constituent class contradicts hasConstituent, the Collection usage note recommends the transitive hasPart for collection contents, and hasConstituent is used for three different relations. A separate module puts the distinction into the structure, not just the usage notes.
3. OntoUML alignment needs a home. OntoUML distinguishes componentOf, memberOf, subCollectionOf and subQuantityOf, and qualifies part-whole relations with metaproperties (essential, inseparable, immutable part, immutable whole, shareable). Only memberOf belongs with collections; the rest belong in a parthood module.
4. Modeling guidance for OWL belongs in one place. Transitive properties cannot carry cardinality restrictions or be declared irreflexive or asymmetric in OWL 2 DL. Commons works around this by pairing a transitive property with a simple direct-part property. That pattern should be documented once, with the properties it applies to.

Scope

The module covers parthood relations that are useful in business, regulatory and technical models, mapped to OntoUML part-whole relations where possible. It is not a general theory of mereology: overlap, mereological sums, mereotopology and temporally indexed parthood are out of scope.

Proposed contents

The module would also include:

• annotation properties, or usage guidance, for the OntoUML part-whole metaproperties, which OWL cannot express directly
• usage notes on weak supplementation (a whole has at least two parts) and on the transitive / direct property pattern
• explanatory notes mapping each property to its OntoUML relation type

Changes to other modules

• Collections imports Parthood and keeps comprises, isIncludedIn, hasMember, isMemberOf, Arrangement and the structured-collection classes. It adds hasSubCollection / isSubCollectionOf as a sub-property of hasPart (maps to OntoUML subCollectionOf). hasConstituent is either redefined to mean items of a collection or folded into hasMember, depending on the outcome of COMMONS-XX.
• Organizations and Locations point hasSubUnit and hasSubregion (and their inverses) at the Parthood properties.
• RolesAndCompositions reviews whether Composition should use hasComponent, hasPortion, or both, and adds a note that composition is distinct from parthood.

Migration

cmns-col:hasPart, cmns-col:isPartOf, cmns-col:hasDirectPart and cmns-col:isDirectPartOf are used by FIBO, LCC and other downstream ontologies. To avoid breaking them:

1. Keep the existing IRIs in Collections, declare each one owl:equivalentProperty to its replacement in Parthood, and mark it deprecated.
2. Keep the deprecated IRIs for at least two Commons revisions before removing them.
3. Coordinate the timing with the FIBO and LCC teams.

Open questions

1. Module name: Parthood, PartsAndWholes, or another name.
2. Should the module define Whole and Part classes, or only properties?
3. Should hasDirectPart also be a sub-property of comprises, joining the two hierarchies at the direct level? (Raised in COMMONS-XX.)
4. Name for the portion / sub-quantity property.
5. Whether to declare the OntoUML mappings formally (for example against gUFO) or only in explanatory notes.