Introduction
The ISO 19107 geometry specification has some constructs regarding curves which were counterintuitive to me. As I do not really understand anything unless I can explain it, this page represents an attempt to collate and digest some answers received on the GeoAPI development mailing list. This discussion concerns ISO/DIS 19107, which is distributed by the OGC as Topic 1: Feature Geometry.
As you read this page, keep in mind that much of the discussion may be centered around conceptual differences among the parts of curve geometry. This may have been the starting point, but the UML diagrams and the accompanying text are the content of the standard. These UML diagrams represent an expression of this mental conceptualization in a formalized framework. The expression of concepts may result in artifacts not present in the original conceptualization. Software systems must deal with these artifacts and if these software systems are to be interoperable, then a common treatment of artifacts must be adopted by all implementations. Decisions about how to handle artifacts are best made by those who grasp the concepts. This excludes me presently.
The Question
To express my question, I require a simplified version of Figure 15 from ISO 19107:
In summary, my brain viewed the relationship between Arc and ArcString (or between LineSegment and LineString, etc.) as an aggregation. I considered a LineString to be made up of many LineSegments. I was thinking that a LineString is a special type of curve just the same way that a PolyhedralSurface is a special type of surface. As such, I viewed inheritance as a really wierd way to express aggregation.
Artifacts
The particular UML expression of geometric concepts in 19107 contains artifacts which started me on this quest to figure out what was "really meant". There are three artifacts visible in the above diagram and in the explanatory text associated with the classes in the above figures:
 A line string and a line segment are both considered to be curve segments. According to the UML above, both are legal targets of the Segmentation association. So line segments may be aggregated into a curve (and no longer be a curve segment), or they may be aggregated into a line string (and remain a curve segment, and hence be aggregated again into a curve). So what is an aggregation of line segments? Is it a curve or a curve segment? If it can be both, what is the conceptual difference between a curve and a curve segmentespecially if a curve segment can have subsegments?
 This duality exposes another artifact: curves and curve segments both implement the interface GM_GenericCurve (see above figure). The meaning of some of the interface properties depends upon the implementation! Specifically, at the very least,
param()
,startParam()
, andendParam()
respond differently if the implementing object is a curve or a curve segment.  Finally, curves are totally self contained (e.g., a curve always starts at 0 and ends at some terminal length), and curve segments must be cognizant of a collection maintained by a different object (e.g., a curve segment must start at it's relative position within the collection of curve segments and end at it's terminal distance later.) Additionally, the curve segment must traverse a oneway association in the wrong direction in order to properly implement its interface contract.
These artifacts cause a certain level of heartburn from a software design standpoint. Number three, in particular, represents very poor separation of concerns. Regardless of what the abstract notion of a curve may turn out to be, on the software engineering side of things a curve should be responsible for maintaining the relationship between the contained curve segments. Curve segments, when contemplating their startParam()
should not have to "figure it out for themselves" using a different class's data.
So this page is an attempt to understand how to cope with (at least) these artifacts. Keep this in mind as we delve into the abstractions and history of geometry. Any concepts developed here must make good sense from a software implementation standpoint or else they're not very useful to a software library.
Response
This question prompted a response from the editor of ISO 19107, Dr. John Herring. The remainder of this article is my attempt to reformulate that response in my own words (with ample quotes from the good doctor) in order to see if I understand it correctly.
Geometry and Coordinate Representation
Geometry is a distant memory to me now, so failing to grasp this distinction is probably the root of my problems. It appears that Geometry is related to coordinate representation by extension.
 A curve is an amorphous one dimensional wiggly thing. It is one dimensional because it only has one degree of freedom. However, it can wiggle through one, two, or three dimensional space. A curve is like railroad tracks on the landscape: the tracks can be laid down wherever you please in 2D space. If you have the energy to tunnel or build bridges, then the tracks may be considered to wind through 3D space. However, once laid the tracks provide only one degree of freedom: position along track. A curve has shape, but no way to quantify the shape with respect to any outside coordinate reference system (e.g., can't say tracks turn to heading 255 degrees at 35N 114W).
 A curve segment is a way of specifying the path of the tracks through the surrounding space. Curve segments are capable of translating back and forth between "position along the track" and "external coordinates." This quantitative knowledge unambiguously specifies shape, orientation and location. Therefore a curve (which doesn't care about location in an external CRS) can be constructed from curve segments, but not the other way around. To construct curve segments from a curve would require extra information, like orientation in the external CRS.
I gather from this discourse that there are two separable factors which logically distinguish a curve from a curve segment. The first is the notion of abstract geometry (curves) vs. coordinate geometry (curve segments). The second factor is the natural tension between algebraically wellbehaved curve segments and the more general notion of a curve which may or may not have a single simple defining equation (but which must be composed of algebraically wellbehaved segmentselse the infinite number of points along a curve couldn't be summarized by a finite number of parameters, ergo: be represented in a finite computing machine.)
Mathematical Notion of Orientation
References
Reference 
Comment 

Good technical read 

Good coverage of historical perspective 













