User creates a Person instance with id PersonA - this is registered to the Registry
User creates a second Person instance with id PersonA and all the same properties - this currently overwrites the first but the result is unchanged
Scenario 2 - complementary information
User creates a Person instance with id PersonA - this is registered to the Registry
User creates a second Person instance with id PersonA and different but not conflicting properties - this currently overwrites the first and loses the original properties
Scenario 3 - contradictory information
User creates a Person instance with id PersonA - this is registered to the Registry
User creates a second Person instance with id PersonA and conflicting properties (e.g. different values for a property with a str value - this currently overwrites the first and uses the new properties
Scenario 4 - same id, different class
User creates a Person instance with id PersonA - this is registered to the Registry
User creates a Group instance with id PersonA - this currently invalidates the RO-Crate by creating a second object with the same id but stored under a different class in instance_dict
Expected behaviours
Scenario 1 is reasonable and efficient. Determining the identity of the two instances would be much more expensive than simply replacing the object. Any fix for scenario 2 would however require such a test.
Scenario 2 could be addressed by adding all values from the second dictionary to the first - this would also work for scenario 1, even if less efficiently.
Scenario 3 would require checks to compare all values. An exception could be raised if this case is discovered or a warning could be logged and the code could otherwise succeed. The latter may be a good way for us to explore how common the issue is.
Scenario 4 probably merits an appropriate check and throwing an exception. This would require an efficient way to check all ids already registered for any class. Such a dictionary could also optimise processing choices for scenarios 2 and 3.
Scenario 1 - identical information
Scenario 2 - complementary information
Scenario 3 - contradictory information
Scenario 4 - same id, different class
Expected behaviours
Scenario 1 is reasonable and efficient. Determining the identity of the two instances would be much more expensive than simply replacing the object. Any fix for scenario 2 would however require such a test.
Scenario 2 could be addressed by adding all values from the second dictionary to the first - this would also work for scenario 1, even if less efficiently.
Scenario 3 would require checks to compare all values. An exception could be raised if this case is discovered or a warning could be logged and the code could otherwise succeed. The latter may be a good way for us to explore how common the issue is.
Scenario 4 probably merits an appropriate check and throwing an exception. This would require an efficient way to check all ids already registered for any class. Such a dictionary could also optimise processing choices for scenarios 2 and 3.