[04:50:13] I have general solutions for the Object ones and root Enum ones, otherwise the error handling isn't as bad (re @vrandecic: I can disconnect the converters, let you work on them, and then connect them again. Whenever we're both online.) [10:44:19] I think it is fairly innocent and consistent (unless you give it a string, which probably just needs special-casing, see Z22475) [22:07:25] The latter is what the function model refers to a “normal form”. The former contains implicit references to Z40 and Z41, so it’s not in “normal form”. (re @Feeglgeef: Normalized is {"Z1K1": "Z40", "Z40K1": "Z41"} vs {"Z1K1": {"Z1K1": "Z9", "Z9K1": "Z40"}, "Z40K1": {"Z1K1": "Z9", "Z9K1": "Z41"}}) [22:36:37] May I cheekily refer you back to [[Wikifunctions talk:Representing identity#Questions]]? I doubt it answers all your questions (then or now) but it almost lets the cat out of the bag, as I read it, suggesting that marking a key as an identity key is more about system behaviour than theoretical correctness. (re @u99of9: This says "Some types, such as string or numbers, do [22:36:37] not need [22:36:37] an additional key, since their value is their identity." So why is...) [23:09:11] It’s too broad, but the Wikidata item selector already allows us to find an element’s QID, guiding me to Q682 if I type “sulphur” rather than “sulfur”, or Q1108 if I type “Cs”. We should be able to restrict the search to items with a P31 link to Q11344. Parallel types are a little complicated, as we already see with Rational numbers and float64, for example. A pos [23:09:11] [23:09:12] sible alternative is convert to code as an object (a dictionary, for example), so that code can access the atomic number, element symbol, QID etc (?), according to its needs.