The discussion over on Practical Knots relating to 'What Defines a Bowline...' is dying out without having achieved any agreement or consensus. However, it did provide an invaluable platform to consider one aspect of a working definition in terms of the bowline's functional components.
The Lexicon of Nodeology already contains terms for the
parts of the bowline loop knot-
It has a .Load, a .Ring and a .Tail_End, and it is classified as a K.Ring_Type binding, but that is as far as the Lexicon presently goes, it looks at the whole .Binding, and not within the actual .Knot itself.
In the 'What Defines a Bowline...' topic, I proposed that the bowline .Knot had two functional 'Components', these being the Bight Component (BC) and the Half Hitch Component (HhC) and that these were arranged so that they were mutually contained by each other.
That is how the knot starts out having been carefully dressed and set, but as I have mentioned before, I see 'knots' as dynamic analogue force machines, that is, machines which respond in a continuous (analogue) manner to the work they are doing or forces they are balancing. The Bowline turned out to be an excellent example of how the components responded to load, in particular, how the Half Hitch Component progressively morphed under load into a Turn Component, with the potential to proceedfurther into an opening helix (right hand helix for the ABoK 1010) under certain extreme conditions.
This lead me to realise that the components themselves were dynamic as well as interactive, and that we should probably need to go yet further and consider the .Elements of the .Components. This is especially important if we want to be able to 'work with' /describe the Simple Hitch - Half Hitch - Turn - Helix progression.
So - .Bindings are made up of parts such as SP, .Knot, loop, end etc
.Knots are made up of .Components (.K.Components)
and .Components are made up of .Elements
and these .Knots, .Components and .Elements all have conditions and properties which respond to load forces.
Note to self - sometimes simplification brings clarity - sometimes it doesn't
I now have to start with some simple examples to identify a basic set of .Components and see if it is possible to identify .Elements and the properties that define them...
Derek