Cradle-to-Gate and Cradle-to-Grave System Boundary Subclasses

[sgranite]

With System Boundaries, there are two types that are generally used. These include Cradle-to-Gate and Cradle-to-Grave. In reality, Gate is a subset to Grave, as Grave tracks the entire lifecycle of the product. Gate tracks the product to the end of production.

[gioUbbiali]

Thank you, Stephen @sgranite, for your input!
Here are just some quick thoughts for discussion.
Here are just some quick thoughts for discussion.
LCA Cradle-to-Gate and Cradle-to-Grave are analytical “boundaries” that you set during your LCA analysis. When dealing with a system, authors define the actual “concrete” boundaries of reference of the system of interest, like where the system starts and finishes, across levels and scales. Further, when performing an LCA analysis, analytical boundaries are constructed above these previously defined system boundaries to foster and allow analysis of that system of interest. So, it seems that there are two layers of description to represent: the actual “concrete” system boundaries and the related analytical boundaries. Cradle-to-Gate and Cradle-to-Grave boundaries refer in some sort to “concrete” system boundaries.
Thus, it seems to me that we need some classes to represent this distinction, probably some “generically dependent continuant” subclasses, like “information content entity” subclasses, and object properties to relate LCA analysis and LCA analytical boundaries to the system of interest and related boundaries.
What do you think about that?

Further, do you think that the place of those classes is in SCO or maybe in a more domain ontology extending SCO for LCA? I’m more inclined to the second option.