Deprecate 'is made of' and 'is material of'

[APCox]

BFO uses parthood to handle the constitution of a continuant. As such, these relations provide a duplicative means of representing the constitution of a continuant and should be deprecated.

[APCox]

For additional clarification:

is made of (ont00001991) is currently defined as "An object o is made of an object m when m is the material that o consists of and that material does not undergo a change of kind during the creation of o"

Following BFO (see section 4.1 of this paper: https://philarchive.org/archive/OTTBBF), the composition or constitution of a material entity can be modeled using instances of the appropriate type(s) of Portion of Material X. Hence, is made of (ont00001991) provides a duplicative means of modeling composition and should be deprecated along with its inverse.

[APCox]

During discussion, it was also pointed out that the is made of relation is overly strict because it does not allow for representing entities that are made of materials that did undergo change during the creation of the end product, e.g., making a wall out of concrete that undergoes a chemical change while curing to form the wall.

Approved to create a PR to deprecate these object properties.

[APCox]

@cameronmore Please provide your rationale for maintaining these relations.

If possible, please also address the current restriction that:

"m is the material that o consists of and that material does not undergo a change of kind during the creation of o"

I believe the original rationale behind this clause is that many materials undergo (e.g., chemical) change when used to produce an output object. For example, charcoal is created by burning wood in a low-oxygen environment. A portion of wood is an essential input to the charcoal production process, but charcoal is not made of wood in the current sense. Hence, an example of the intended use of is made of would be:

CharcoalBriquette1 is_made_of PortionOfCharcoal1

If these properties are to be preserved, this needs to be addressed to provide users with greater clarity regarding when it is or is not appropriate to use this property, as well as what representation to use when is made of is not appropriate. This is particularly relevant because people tend to say things such as, "Concrete is made of Portland cement, water, sand, and gravel." But this "ingredients list" sense of is made of is not what the CCO property is made of represents.

[BrendaBraitling]

@APCox - It is in use. Here is just one paper found in a 5 second, casual search.

About Deprecations - amplifying your suggested approach:

If these properties are to be preserved, this needs to be addressed to provide users with greater clarity regarding when it is or is not appropriate to use this property, as well as what representation to use when is made of is not appropriate.

A redundancy can be noted, but - as you indicate - it is a good idea to determine who is using it and for what reason. It may allow a new feature to be developed later and any harm in using it, as is, can be identified.

I am not sure why a unified CCO is better than CCO as a suite... However, mapping all discovered equivalent redundancies and publishing a proposed unification plan to your user-base for comment - before any deprecation happens - seems the wisest course of action. It will help you gather use cases and build good will with your user-base.

To amplify your thought: All identified redundancies in the unified CCO can be reviewed as a package - purposefully and efficiently - by the widest base, allowing harmful ones to be identified and prioritized for change.

General comment about public projects, graciousness and good will...

When a product is in wide use by developers, it is a best practice to have a public communication plan which provides a product road map and partners with the user-base to prioritize changes and mitigate the risk of those changes. This is especially true for open-source products, standards and regulatory requirements. These products are developed for public use, rather than internal enterprise use or strategic product development within an organization. Compared to internal development, the process may seem to run in slow motion...

In general, after any product is released, changes should be driven by concerns, not efficiency. They should be raised by your user base when they request a new feature or bug fix. Proposed breaking changes and deprecations should have a well publicized and long comment period - and are generally not pursued unless there is a strong reason...

Working with your user-base is what makes your product valuable. They require functionality and stability to use the product... even if they need to use a version you may have chosen to leave behind.

[johnbeve]

@APCox These relations should be deprecated or the labels changed to avoid confusion. At a minimum, the labels conflict with underlying BFO commitments, resulting in confusion (as we both noted in the most recent BFO-CCO office hours call).

@BrendaBraitling This issue is not the appropriate forum for general discussions about deprecation strategies. We have a dedicated Discussion space for such things; please use that in the future.

[APCox]

@johnbeve Regarding option 2 - change the labels: What are you suggesting here?

[johnbeve]

See #715 (comment)