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 (#5295): https://lists.spdx.org/g/Spdx-tech/message/5295
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]]
-=-=-=-=-=-=-=-=-=-=-=-
