After some first evaluation, I still quite like the basic input concept offering as few input elements as possible and having the software make a best guess. This interface simplicity, however, has some implications. Those are, at least:

• The software needs proper logic for making best guesses.
• It is not obvious how some options may be set instantly, for example: uncertainty options like "before" and "lower bound". The question is, per option, whether it can be regarded primary or secondary. The term "advanced options" currently in use, probably, is not the right expression.
• The preview needs to be specific enough to make the user aware of additional adjustments (e.g. planetographic coordinates may probably need to display the globe unless there is some other concept that defines the globe, for example, per Property resulting in some Property like "position on Venus").
• Experienced users should be offered ways to enter information specific enough in order to circumvent false guesses (i.e. by entering something like "1 7 2015 Julian") in order to get around clicking through the secondary options.

The concept is simple: Enter something, have the software present the guess (preview) and ask the user whether that is what the user expected. If it is not, the user may open detailed input components. This keeps the UI unobtrusive and accessible for new users.

(Could also be something like "Not what you expected?" or "Not what I expected?" for a more personal address. Appending some phrase like "Refine [date/amount/coordinates/...]." would emphasize the hint about additional input options even more.)

Everyone of the existing data types can have one input box as its only primary input method, except, maybe, monolingual text. However, I wonder why the language of a monolingual text value should not be specified directly on the Property. Very likely, at least multilingual text and geographic shapes need some more sophisticated primary input, but the basic concept should remain the same. Keep it simple by not filling the page with input elements a user most likely does not need anyway.

In my opinion, the actual issues are more on a per data type basis. Time data type is most prominent here as the UI for it is not as flexible as it should be and, even more, is missing options. As mentioned, "advanced adjustments" may change to something more "communicative". Apart from that, I would propose creating tickets for the input concept of each individual data type and evaluate one by one about primary input, secondary input and how to integrate these aspects.