I haven't been able to catch up too closely with the discussions - (but am going to start doing that now). I do find the ability to not have a canonical representation of each element within the specification of the graph difficult for parsing, ideally the SPDX ID namespace mapping would be available during the first round of parsing. I do see the ease of this format where you could easily combine multiple documents into one, but we'd run into ID collisions in this case where we can't disambiguate between two IDs referenced from different SPDXDocuments.
Elements in SPDXDocument feels like a special case, which I think would be nice to be able to have easily retrievable at the start, and rootElements seems like a relationship as well (feels like the shortcut fields again)... I look forward to being corrected though :). 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 (#5296): https://lists.spdx.org/g/Spdx-tech/message/5296 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]] -=-=-=-=-=-=-=-=-=-=-=-
