...
In some sense, the resolved field in all of the above solutions is an anomaly, because it requires different treatment for persistence and retrieval. On committal, it should always be empty; on retrieval, it should be populated - potentially this might be conditional on some request flags. Another approach is to define different types for storage and retrieval, as follows.
In the above, the persisted form of a Problem List consists of SECTIONs, CITATIONs and possibly other primary ENTRYs, if needed within the list (i.e. orange and violet objects). The retrieved form consists of SECTIONs, RESOLVED_ENTRY<CITATION, EVALUATION>ENTRY<CITATION> etc, each pointing to the original CITATION objects, the resolved target ENTRYs (or other content, e.g. RESULT_SET from a query), and any other primary ENTRYs (i.e. orange and yellow objects, each of which points to a purple object and a copied orange object).
The class RESOLVED_ENTRY doesn't need to be generic as above, this is just one way of doing it to make resolved Entries related to the type of view entry on which they are based.