> > The net-net of my thoughts on these matters is the following: > > - The current SpdxDocument class should be removed from the model > > +1 to Gary's proposal to defer naming the class currently called SpdxDocument.
> > - Bills of material should be represented with Bom (or its subclasses) > instances > > Definitely, and other element collections such as Bundle are subclasses of ElementCollection > - Metadata for specific serialization instances should be represented > with File class instances > > Name not chosen yet. > > - A new special direct subclass of ElementCollection should be defined > (a couple of name suggestions above but not "SpdxDocument") to be an "outer > layer" collection enforced with a constraint on the 'element' property of > ElementCollection that it cannot contain this new "outer layer" type of > collection thus preventing layering > > Definitely not. A pile (rhymes with "file") of serialized element values is not an ElementCollection, nor is the unnamed "X" element that describes it. A set of elements can be parsed from one, two, or more serialized piles; there is no association of a single element to a particular pile in the model. A single element can be in and be parsed from many piles, which can have the same or different data formats. > - The NamespaceMap should be placed on the new "outer layer" type of > collection class thus avoiding the potential conflicts and complexities of > prefix layering > > A NamespaceMap exists in the pile to enable compact serialized data to reconstruct full element instances. An "X" element class does not need to exist at all to parse a pile into full element instances. If an X element does exist, its namespace map has nothing to do with element instances, only how much compaction is applied to other piles - a given SpdxId instance is serialized into: full IRI, short namespace + long local id, or long namespace + short local id. - NamespaceMap does not exist at all in element instances (the logical model). - I agree with Max's proposal that a consumer can create an "X" element for a particular pile that it parses some elements from. The consumer can then include that "X" element in piles that it produces, to allow external references from the produced pile to the consumed pile. - There is no such thing as "external" in the element graph; an instance with an id exists or it doesn't. "External" is a concept that applies only to serialized data piles, it doesn't exist in the logical model - The use case of Payload A -> Logical Element Store -> Payload A` where A is destroyed but A' must use the same namespace map as A would require that namespace map be included in an element. But I question the validity of requiring that Payload A be destroyed. If that were true, source integrity from the Producer of all elements in A would be lost. Not to mention that it's as illogical as saying that a File element must be able to reconstruct the original content in file A' from the element store if original file A is destroyed. On Thu, Aug 17, 2023 at 10:45 AM Sean Barnum <[email protected]> wrote: > All, > > > > After our discussions around NamespaceMap and SpdxDocument in our Aug 8th > tech meeting I put a little more thought into these challenges. I recognize > the implementation complexities around prefix layering that Gary and others > were expressing deep concern with and respect their perspective. Given > these expressed concerns but still remaining issues in the current > approach, after some further thought I believe I have a compromise to > propose that seems to address all of these issues cleanly. > > > > Summarization of my thoughts are: > > > > - There have been previous discussions that putting NamespaceMap on > ElementCollection gets very complicated because collections can contain > collections (to an undefined depth) and there is a potential for prefix > conflict. I would concur that this is a challenge of significant complexity > to fully address. > - There is existing confusion even from people in the tech working > group on the relationship/difference between SpdxDocument and Bom. This > includes questions on whether SpdxDocument is needed in the model. It was > conveyed on the call that the purpose of SpdxDocument was to convey > metadata for a specific serialization instance of SPDX content. > - Having SpdxDocument in the model if it is intended to convey > metadata for a specific serialization instance creates a messy situation as > it conflates the model with specific serialization which is a separation > that is very important to maintain for simplicity, flexibility, > consistency, etc. > - Details about how to serialize and specific instances of > serialization should be specified and managed outside of the model. > - If we want to convey verifiedUsing details of a specific instance > of serialization then we should use a File Element to represent the > serialized file and assert the verifiedUsing details on it. We could > also > then relate that File to the content Elements it contains (hopefully > typically a single wrapping collection) with a "contains" Relationship. > This is an appropriate way to handle metadata for a specific > serialization > instance and not confuse the model. > - There are cases where instances of serialization may not involve > a file and this would call for the need for a ContentData (chunk-o-bits) > Element which we have in prior discussions scoped to after 3.0 so for > 3.0 > instances of serialization would only be Files. > - To simplify a solution for NamespaceMap in layered collections it > does make sense to specify a special subclass (directly) of > ElementCollection that is intended to be a collection that no other > collection can reference as an Element (thus preventing layering). This > special subclass should not be thought of as specific to serialization but > rather just a special kind of collection in the model. This layer > prevention would need explicit assertion in the RDFS/OWL and in the SHACL > such that the range of the 'element' property on ElementCollection would be > Element but NOT the outer-shell collection. I would propose not using > "SpdxDocument" as the name of this class as it has a lot of history and > would have the potential for a lot of confusion. We should choose another > name for this class that conveys that it is an outer-shell-only collection > and namespaceMap can be a property on it. We could go with something simple > like "EnclosingCollection" though that name does not inherently convey lack > of layering. Another more esoteric but explicit possibility could be to > maybe borrow from chemistry and we could call it "ValenceShellCollection" > given the universal usage of the term 'valence shell' to be the outermost > layer of electrons in any atomic element and the layer that reacts with > content outside the atom. This seems pretty close to what we are trying to > convey. > > > > The net-net of my thoughts on these matters is the following: > > - The current SpdxDocument class should be removed from the model > - Bills of material should be represented with Bom (or its > subclasses) instances > - Metadata for specific serialization instances should be > represented with File class instances > - A new special direct subclass of ElementCollection should be defined > (a couple of name suggestions above but not "SpdxDocument") to be an "outer > layer" collection enforced with a constraint on the 'element' property of > ElementCollection that it cannot contain this new "outer layer" type of > collection thus preventing layering > - The NamespaceMap should be placed on the new "outer layer" type of > collection class thus avoiding the potential conflicts and complexities of > prefix layering > > > > > > Thank you for your consideration. > > > > Sean > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5297): https://lists.spdx.org/g/Spdx-tech/message/5297 Mute This Topic: https://lists.spdx.org/mt/100801657/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
