> > My assertion on the call is that any presumption of “globally unique” > based soley on the probability space of possible values is a poor general > approach because it does not explicitly take into account the instantial > value space where the number of objects may be very large and increase the > probability of collisions. It does not deterministically prevent > collisions. While extremely unlikely, it is possible to have a conflict > with only two objects.
You should speak with a cryptographer. For a 256 bit hash value, the chance of birthday collision is 1 / 2^128, or 1 / 3.4*10^38. That's 10 with 38 zeros. For comparison, the chance of winning the Powerball lottery jackpot is 1 in 292 million, or 1 / 3*10^8, so the chance of collision is about the same as the chance of winning a powerball jackpot 1,000,000,000,000,000,000,000,000,000,000 times in a row. The age of the universe is 436,117,076,640,000,000 seconds, so you'd have to be running those lotteries at 1,000,000,000,000 times a second for the whole age of the universe before getting a 50% chance of a collision. Compare that to the reliability of trying to deconflict namespaces using a global registration system. "Extremely unlikely" is easy to say, but it doesn't come close to doing the mathematics justice. The chance of collision due to an error in a global managed system is infinitely greater (yes, that's hyperbole) than in a cryptographic system. So, to support use cases such as linked data we need namespaces to be URIs > themselves. Yes, that goes without saying, just as UUIDs are included in URIs. I am avoiding using “local id” as it may imply that that portion of the > identifier is only local to that namespace That's OK. The identifier is local to the namespace, and since it can be anything within a namespace, nothing prevents many namespaces from using the same id. The full "namespace:id" is different, meaning the Elements are different regardless of whether the ids are the same. I think "component" is misleading because it implies that several namespaces using the same id are using it to refer to the same "thing"/component, which clearly is not required. The id has no semantics, it is opaque, but I'm not going to quibble over what to call it. I think it is important that we realize that the identifier (idString) is a > valid URI that is composed of the namespace and the component id. It is not > adequate to split these properties and store them in separate properties. On the contrary, it is essential to recognize that the model represents semantics. By using the words namespace and id we are assigning meaning within the compound identifier. Pretending that that meaning doesn't exist, wishing it weren't real, and modeling an Element identifier as a lump without two components is the root cause of the discussion going around in circles for months. Sebastian observed that the "#" character (or whatever other character we use) is not part of the semantics at all, it is part of the syntax. Taking a namespace and an id and forming a single Element identifier (and putting that identifier in URI format) is by definition syntax, whenever and wherever it is done in any kind of application. The Element identifier always has a namespace and an id, that's its semantic meaning across all applications, period. Each serialization of Elements MUST maintain integrity and consistency of > the fully composed identifier string during serialization and > deserialization. I fully agree. You say that Elements don't have to be associated with any document. If those Elements have integrity and consistency of their identifiers, and they aren't associated with a document, then wherever they come from they must have a proper namespace and id. Gary suggested Elements could come from single-element documents that provided the namespace for that one Element; that's certainly possible. I haven't seen your non-Document serialization, but I agree that it too must provide a proper compound identifier for its Element. Dave > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4149): https://lists.spdx.org/g/Spdx-tech/message/4149 Mute This Topic: https://lists.spdx.org/mt/84649986/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
