Unidirectional "Composition" aggregation implemented in the backwards direction too.

Dr. John Herring (editor or 19107) addressed the issue of providing role names for the reverse direction of associations in the GeoAPI-devel email list. The relevant excerpt is attached here:

As for backward, but non-navigable pointers being named, this actually makes sense, if you realize that navigability is a representation issue. Association roles that need to be navigated often, need explicit ways to get about, those that aren't navigated often can be reconstructed by other means (scanning the entire dataset if necessary, but indexes work fine, too).

So for example, the relationship between curve segment and curve is only navigable from GM_Curve to GM_CurveSegment, but is named and
given a cardinality in the other. There are reasons for this. First, the association is a strong aggregation, and a curve segment can exist only in one curve at a time. On the other hand, a GM_CurveSegment can be implemented independently of its containment in GM_Curve and so can
exist independently of the class GM_Curve (although maybe not persistently). This is not the usual interpretation of a strong aggregation, and so the "curve" role in the association is given a "0..1" cardinality, saying the segment can be in a most 1 curve, but can exist without a curve. A bit amusingly, the GM_Curve class cannot exist without a least one GM_CurveSegment (1..* on the segment role). The logic here is that a geometry is useless unless you know where it is. Of course, this is almost the definition of topology, and so like most absolutes, it is questionable. Note that in 19107, topology can exist without geometry, but geometry cannot exist without coordinates. There is a lot of blood on the bridge on that one.

Of course, some behavior between curve and curve segment is common and thus GM_GenericCurve (an interface) was created to hold what we thought of as the most important common behavior, as common operations.