Jacopo, If we normalize the data and reference PartyRole from PartyRelationship, and remove the fields:
partyIdFrom partyIdTo roleTypeIdFrom roleTypeIdTo fromDate thruDate And replace them with: fromRole toRole Then we will eliminate this confusion. We would still of course use PartyRelationship, and not depricate it. In the business login and security, we will need to check both PartyRole and PartyRelationship depending on what the service is doing. For searching, and party lookups, I completely agree with you. We can still sort them and search role type to obtain a PartyRelationship. Thank you. On Sun, Oct 12, 2014 at 1:19 AM, Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com> wrote: > On Oct 12, 2014, at 7:09 AM, Jacopo Cappellato > <jacopo.cappell...@hotwaxmedia.com> wrote: > >> a) deprecating the party role entity > > One clarification: I didn't mean to say that we should remove the party role > entity; in fact it would be still useful because, in order to play different > party relationship, we will need to store different information for the > party; the party role entity is useful to tell you what are the roles that > can be played by a given party; what I meant to say is that in mostly all > business logics/screens we should replace lookups to party roles with lookups > to party relationships. > > Jacopo