When doing this for scientific protocols I found that you basically have to give up any hope of specializing types of things. The domain ontology for documentin

When doing this for scientific protocols I found that you basically have to give up any hope of specializing types of things. The domain ontology for documenting processes, be they making cupcakes or electron micrographs, has to be matched to the domain in question. Some might say that for processes this means everything must be extremely abstract in order to avoid edge cases like those encountered by the author. However, I would argue that from the perspective of someone executing a recipe they do not care at all about whether something is edible or food or not, they only care how much they need of something (count is a unit(less) of measure). Thus, the ontology proposed by the author is not matched to the domain. The first mistake was trying to make a distinction between food and non-food. What if I used paper cupcake cups? They may not technically be food, but I have certainly eaten parts of them before by accident. Other parts of the system might care about food/non-food, but these parts are constrained by a separate and likely orthogonal set of use cases. I don't usually need to know the chemical formula for sodium bicarbonate to order it from a vendor, but if I need to automatically calculate stoichiometry for reactions so that I can automatically order the correct amount then I might. Those two parts of the system can and should be completely orthogonal to each other and thus fully decoupled. Therefore, I would suggest that encountering something that looks like "edge case poisoning" is a sign that you have not properly factored the system.