Alternative propose to #64 - support for defining relationship lookup…

[paulo-graca]

This PR was created in a tentative to explain our point-of-view for what #64 should be changed.

According to the document - https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.5bu9shx0j942

You will have what it's called Closed or Open Relations. A closed relation is defined when you have fields in a submission form that only relate to Entities, but those fields are "stuck" to Entities, will not have mixing Entities and text values. For Open Relations you will need a special solution if you want to mix text valued and Entities. @benbosman and Atmire proposal for that, include a flag parameter ("relationship": true) to enable relationships in existing field types.

We have a different vision for enabling relationships at the form submission level, which should include the creation of two new and different components to accomplish this open and closed relations concept. The "relationship" type should be used for closed relations and "relationship_open" when you need to mix Entities with text values.

The main reasons for this approach has to do with simplicity (don't introduce more complexity in the existing form field types), separation of responsibilities (you will have specific field types to handle the relationships, if one doesn't want to use Entities in DSpace, he can use the system as already provided, without the Entities+Relation) and historically DSpace introduced different field types (onebox, twobox, names - all for text fields) when the need to add more fields occurred.

But I also see the advantages in the solution from Atmire, like with a single flag you will open the fields configuration for Relationships, but, at the same time, that property shouldn't be applied for all field types, for instance textareas, or dates, or even dropdown (controlled values). In theory, you will not have open relations for this kind of fields, there are only some use cases when this might happen and the only one that I can recall it's the author's name. That can be perfectly implemented using a relationship_open. With a single text field for storing text. Of course one can argue that we will loose stuff, for instance, Authority Control. Is there any real Use Case of having Entities along with Authority Controlled values?

[paulo-graca]

The group decided to go ahead with #64, leaving this as an alternative if we need to revisited. A new jira feature request was created to address this - https://jira.duraspace.org/browse/DS-4302