Ambiguous parent-child relationship of some notations

[xadler1]

In notations.txt there are some notations, which appear as children of multiple (usually two) other notations. For example 11HH is listed as child of both 11 and 11H.

N 11
K 11k
C 11A
; 11B
; 11C
; 11D
; 11E
; 11F
; 11G
; 11H
; 11HH                                                                                                                                                                
; 11I
; 11K
; 11L
; 11M
; 11N
; 11O
; 11P
; 11Q
; 11R
; 11S
; 11T
; 11U
; 11V
R 7
$
...
N 11H
K 11k
C 11H(...)
; 11HH                                                                                                                                                                
$

There are little over 2600 other notations with the same problem, listed in duplicate-notations.txt. Is this intended?

[epoz]

Dear @xadler1

Thanks for catching this, I think it is a historical error, which I never looked for before, and never caused any obvious errors.
It never occurred to me to write a script checking for "mutliple parents". There might be more!

Do you mind submitting a pull-request fixing this? And we can then accept it straight away.

[epoz]

...and looking at your duplicate-notations file, I can see where the error comes from.
In ancient versions of the system (the printed books and in the C-library) - it was possible for the double-letters to be reached from multiple places. So there was not really a "canonical path" - when you went parsing backwards from a notation.
At some point I considered it expedient to have the double letters be a "child" of the single -letter variants when browsing a tree.

[xadler1]

Thanks for the quick reply. I wasn't quite sure which parent was the correct one, but now that I know there is a rule, I could create a pull-request.

[epoz]

Dear @xadler1

I was looking at this pull-request again today, thinking it could be just accepted, but then I realized it needs more discussion with the editors. For example, if we look at notation https://iconclass.org/11 it has both 11H Saints and 11HH Female saints listed as "children" - which is very useful for end users. But then indeed , looking at https://iconclass.org/11H we also have 11HH Female saints listed as a "child" for convenience sake.

If you consider this from a network analysis point of view where you want one canonical "path" to a notation, it is wrong. But from a user point of view, this is convenient. So we need to solve this more elegantly I think.
One option that springs to mind is to solve it by removing the superflous "children" links, but adding a "See also" to those items.
So in other words, for eg. the new entry for 11H becomes:

N 11H
K 11k
C 11H(...)
R 11HH
$

(and also for the other items)