Why do `EdgeChange` operations have both an `about_edge` and {`subject`, `predicate`, `object`} slots?

The `EdgeChange` class has an `about_edge` slot of range `Edge`, which itself has three slots `subject`, `predicate`, and `object` to represent a typical RDF triple / OWL axiom / graph edge, etc.

But several of the subclasses of `EdgeChange` have also their own `subject`, `predicate`, `object` fields, _in addition_ to the `about_edge` that they inherit from `EdgeChange`. For example `EdgeCreation`, `PlaceUnder`, `EdgeDeletion`…

Why is that so, and what is the intended way of using those classes? For example, is the subject of the edge to be created in `EdgeCreation` intended to be stored in `EdgeCreation.subject` or in `EdgeCreation.about_edge.subject`?

Other subclasses of `EdgeChange` don’t have their own `subject`, `predicate`, `object` slots and have instead only the `about_edge` inherited from `EdgeChange` (for example `NodeMove`), suggesting that `about_edge` is the correct way to represent edges and that the “flattened” `subject`, `predicate`, and `object` slots in the other classes might be a mistake.

Compare EdgeChange with EdgeCreation, PlaceUnder, EdgeDeletion, and NodeMove, focusing on about_edge and the subject, predicate, and object slots. Trace the model definitions and any examples or tests that use these classes to determine the intended representation. Done means the project has one documented, consistent usage and the affected model definitions or tests reflect that decision.

Written by the indexing model from the issue text.