Gary, I agree, except that there isn't a need for two concepts. I like the word "mint" used by RDF because what you call "creating" corresponds to the engraving part of the minting process - creating the stamp, and "publishing" is the part where the stamp actually stamps out a coin or bill. The setup part is uninteresting.
If we were signing Elements it would be clear that "creating" is the signing action, and that publication of a signed object is uninteresting because publication of one object can happen in many places at many times. That's why immutability and verification are related - the point at which a mutable object becomes immutable is the point where verification info becomes possible. Whatever word we choose, we just need to make it clear that it happens once per Element, in particular once for a Collection Element. Dave On Tue, Nov 9, 2021 at 12:47 PM Gary O'Neall <[email protected]> wrote: > It may be helpful to introduce a difference between “creating” and > “publishing”. Creation time is the point in time an element is created. > Publication is when the element is first made available for consumption > outside the tools/people/processes that create the element. At the point > an element is “published”, it is immutable. Technically, while an element > is under construction it has to be mutable internally in the tool creating > the element. If we captured “publication time” instead of “creation time”, > it would allow a large group of elements to have the same “publication > information”. I think all use cases are still supported since there is no > visibility to an unpublished element. > > > > Gary > > > > *From:* [email protected] <[email protected]> *On Behalf Of > *David Kemp > *Sent:* Tuesday, November 9, 2021 5:59 AM > *To:* Sean Barnum <[email protected]> > *Cc:* SPDX-list <[email protected]> > *Subject:* Re: [EXT] [spdx-tech] Infinity Category Theory and SBOMs. > > > > Sean, > > We are agreeing but not communicating. Thousands of Elements can have the > same creation info IF they are created at the same time :-). > > An Identity does one "minting" or creation operation at a time. A single > minting operation may mint thousands of Elements, but those thousands of > elements are the "set of Elements that were created by identity X at tick > Y". That set may be an entire SBOM with dozens of Packages and thousands > of Files, or it may be a single Artifact Element, but the point is that > once an SBOM is created with thousands of Elements, it has an ID, and the > set of Elements that are part of that SBOM and associated with that > collection ID never changes after creation. > > On Tue, Nov 9, 2021 at 1:42 AM Sean Barnum <[email protected]> wrote: > > I would very fundamentally disagree with the premise that “no two Elements > have the same creation info”. > > Any Element can have any creation info including creation time. A creator > of SPDX 3.0 content could create 1000 Elements with the same creation info. > > This is not only valid but I would argue is absolutely critical. > > > > And there should be absolutely no presumed dependence or correlation of > creation info between any Elements including (especially) any Collection > Elements. > > > There is no presumption. A creator creates what it decides to create. If > it creates a Collection, then the members of the Collection have either the > same clock tick or a different clock tick than the Collection Element. The > only restriction imposed by physics is that a Collection member must either > exist before the Collection or it is created at the same time as the > Collection. A Collection can't have a member that hasn't been created. > > > At the model level, each element must define its own creation info and not > depend on whether or not it is included in a Collection or even if it was > created at the same time as a Collection it is included in. > > This is the very basis of our first consensus axiom of Element > independence. > > > Yes, agree completely. Each Element *has* its own creation info. If it > has the same creation info as a Collection then it has the same creation > info as the collection. If it doesn't then it doesn't. > > At the model level, a Collection is simply an Element with references to > other Elements. The referenced Elements COULD share the same creation info > as the Collection but it is perfectly valid if they do not. > > > Yes. > > > Similarly, Elements referenced by a Collection may have differing > namespaces even if they were minted at the same time as the Collection. > > > > A namespace is used for serialization. Elements have opaque IRIs, and > defining a namespace (baseIRI and prefixes) at the model level is > optional. If defined in the logical model it allows different > serializations to optimize serialized IRIs in the same way. > > > The issue of ensuring there is no presumed dependence or correlation > between Elements (including Collections) was discussed at great length in > the 3T-SBOM group and was the driver for one of the first topics we > discussed as merged communities to reach consensus on the independence of > Elements. > > I am disheartened to see us returning to those same debates again. > > > As above I don't think we are revisiting anything. Elements are created > by a creator at a clock tick. An arbitrarily large Collection of Elements > can be created by a creator at a single tick. A Collection can have member > Elements created before the Collection or in the same minting tick as the > Collection. An Element does not have to be part of any Collection. An > Element created with one Collection can be members of many other > Collections created after the Element exists. > > Of all the topics we have discussed, debated and compromised on I view > this one as one of the most critical to get right. > > > > sean > > > I agree it is critical to get right. And documented well so that it is > universally understood. > > Regards, > Dave > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4251): https://lists.spdx.org/g/Spdx-tech/message/4251 Mute This Topic: https://lists.spdx.org/mt/86926241/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
