My guess is that eventually we will need to add a "hash" value to the relationship object to store a digital hash of the object you are linking to. We have already started to do this in a few places, like external_references.
Bret
From: Piazza, Rich <>
Sent: Wednesday, June 14, 2017 2:58:10 PM
To: John-Mark Gurney; Bret Jordan
Cc: Wunder, John A.; Patrick Maroney; Jason Mr. Keirstead; ; Back, Greg;
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
I don't think we should give up on the idea of reusing Locations so quickly. Assuming we go with Locations as SDOs, it certainly is a problem if you reuse someone's Location and they change it from underneath you. I was first thinking
that there should be immutable SDOs - in other words, the unique USA Location SDO CAN'T be changed. If we had a set of the common ones (defined in some library/repo somewhere) then we could just use their ids. Duplicates are allowed, but hopefully few
people would need to create their own USA Location SDO. I was thinking of an extra property (on all SDOs?) - final. If final is true for an SDO, then a new version couldn’t be created.
Adding immutable objects to the spec might be a good idea in general, but I think a simpler way to handle this is just to "trust" that the library/repo contains objects that will not change. In other words, locations created by a certain (well-known) identity
(SDO-Immutable-Library) could be reused with little concern that they are going to change. And if they DO change - maybe that is a feature - after all, all those Soviet-Union Location SDOs are no longer too useful...
