Creating and using data are usually different parts of a process, acknowledging this can simplify the system.
Creating data is a simple operation on a low level, basically creating the underlying objects for the
Place roles. Perhaps the
Author is played by a
Place could be an
Using data is what the users does in any useful system, making connections between pieces of information. The
Information Carrier seems to be such a connector. This is what the discussed part of the system should do.
By having an interface like the one you describe, basically a database GUI, it will become too low-level for most users, since they aren't familiar with the underlying data. As stated in your screenshot, when the user thinks about a
Document he thinks about an
Owner and an
Author, not a
Person, which may be the underlying object for both of them, containing pieces of information unknown to the user, but could be required by the data model.
Therefore, forcing/allowing a user to create a
Person in the process of "Connecting information to a Document" is a mental model mismatch and could also be error-prone.
So my suggestion is to split the creation and usage:
Create the basic data objects,
Picture etc. in another part of the system.
The document creation page can now be simplified to only making connections, hopefully everything on the same page to avoid the stack of modal dialogs looming in the screenshot. It should be possible now when it's only about selecting already existing data.
If new data needs to be created, do that in the other part of the system, return to the document creation and update the selection fields, manually or automatically.
If new data needs to be created for most new documents, there could be some information problem that needs to be solved, like importing pre-existing data, or even simplifying the data model so much that most relations will be reduced to a text field. The
Address could be such a case. It's hard to know without a detailed data analysis.