PARTY.reverse_relationships should better be a Set<PARTY_REF> ?
Description
PR is addressed in
Activity
Sebastian Iancu November 6, 2018 at 12:57 PM
and were created, things that should be still addressed in a new CR is :
transform this 'reverse_relationships' attribute into a function, as it is rather a 'derived' information
Thomas Beale November 6, 2018 at 12:38 PM
Can you check in your implementations if PARTY.reverse_relationships is in fact a List<LOCATABLE_REF> and in there are any problems with it?
(Create new CR for fixing LOCATABLE_REF.as_uri())
Bjørn Næss April 26, 2018 at 6:24 AM
I have no strong opinions on this. The suggested changs seems reasonable. I will accept them.
Sebastian Iancu April 25, 2018 at 7:45 PM
To review what is suggested to be done:
transform this 'reverse_relationships' attribute into a function, as it is rather a 'derived' information
keep the 'relationships' as attribute, but should be fixed in 1.0.3/latest to LIST<PARTY_RELATIONSHIP>
description of these two attributes/functions should be corrected by changing 'role' to 'party' (see "Relationships in which this role takes part as source.")
description of 'reverse_relationship' should be changed to be clear that the refs are of the PARTY_RELATIONSHIP and not of the involved PARTYs (see comments above)
LOCATABLE_REF.as_uri() should be relaxed to accommodate non-ehr uri schema
Sebastian Iancu August 31, 2017 at 2:37 PM
Any new comment or impression about this?
Should this be removed?
Would that be better if PARTY.reverse_relationships would be a Set<PARTY_REF> instead of Set<LOCATABLE_REF> ?
Relationships as defined in specifications are always going to be between PARTY objects; furthermore 'path' property of LOCATABLE_REF will never be used in this context.
In the reverse_relationship case the actual kind of reference should be via the use of OBJECT_VERSION_IDs to denote the exact Version of the source PARTY, rather than HIER_OBJECT_IDs.