The new "relationship" and "relation" metadata schemas for Configurable Entities are confusing and have a lot of dependencies on one another. We may want to find a way to combine them (or make them clearer).
The "relationship" schema has one element: "relationship.type". But, strangely, this "relationship.type" doesn't store a type of relationship. Instead it's a type of Item (e.g. relationship.type = Journal).
The "relation" schema stores various relations that exist between specific items. For example "relation.isVolumeOfJournal" would store the Volume UUID(s) for a Journal object. But, strangely, this relationship name seems backwards. Volumes should have "isVolumeOfJournal" relationships (pointing to their Journal), while Journals should have "isJournalOfVolume" (or "hasVolume") relationships (pointing to their Volumes).
In summary, there are several questions here:
- Should we consider combining these concepts into a single internal schema (perhaps named "dspace")? This would allow something like "dspace.item.type" (instead of "relationship.type") and "dspace.relation.[name]" (instead of relation.[name]).
- Should we switch around the relationship names for all Entities? Currently they seem to be backwards (as described above). Metadata should describe the object that it appears on. So, describing a Journal as having an "isVolumeOfJournal" relationship sounds like the Journal is claiming to be a Volume (which doesn't make sense).
Once relation types are finalized, we should also update the RelationshipTypeRestRepositoryIT.getAllRelationshipTypesEndpointTest() method as per this discussion: https://github.com/DSpace/DSpace/pull/2376#discussion_r279388098