I would concur with the comments from Henk and Bob. I think we need to be careful to not conflate the spec, model and its component parts with profiles.
The model and its component parts (core, software, hardware, etc) should define the full picture of what can be expressed for all supported use cases. The spec may provide detail on how to effectively leverage the model to support targeted use cases. Profiles are simply explicitly defined subsets of the model that apply to particular use cases and as Bob said align to compliance points in a formal standard when we get to that point. The subsets of the model relevant to a given profile may be particular component/namespaces (e.g., core & software), may be particular classes or properties, or may be particular constraints on classes or properties. Constraints on classes could be that a given profile specifies one particular subclass of the general model where different profile may specify a different subclass. Constraints on properties may be things like cardinality, vocabularies of values for string properties, etc. Different profiles may define different constraints on the same classes or properties. In general if you define a subprofile or another profile, then the constraints are only allowed to narrow and not broaden. In this way all content of the subprofile is also valid according to the parent profile. Think of profiles as venn diagrams of content expressible by the model. So, I think the discussion around adding or modifying in profiles may be confusing the model with the profiles defined against it. Profiles should never add to or modify the model. They simply identify portions of the model and how they should be used (constraints) for a given context. Sean Barnum C – 703-473-8262 [email protected] We are here to change the world! <https://www.facebook.com/MITREcorp> <https://www.linkedin.com/company/mitre> <https://twitter.com/MITREcorp> <https://www.youtube.com/user/mitrecorp> <https://plus.google.com/+MitreOrgFFRDCs/posts> <http://www.mitre.org/> On 4/6/21, 6:55 AM, "[email protected] on behalf of Alexios Zavras" <[email protected] on behalf of [email protected]> wrote: Right. Henk, it might be useful to think that our "profiles" are similar to "Bluetooth profiles", listed in https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles. Each one (like Headset profile, or Serial Port Profile) adds some new information and a specific device might use only a couple of them. Our problems, discussed in this thread, comes from the interaction between profiles. [sorry for following up so late -- Easter holidays] -- zvr -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Martin, Robert A Sent: Thursday, 1 April, 2021 21:11 To: Henk Birkholz <[email protected]>; Gary O'Neall <[email protected]>; [email protected]; [email protected] Subject: Re: [EXT] Re: [spdx-tech] interactions between profiles Hi all, At the risk of adding confusion but the intention of helping bring clarity I will offer that the idea is to have a specification with a core that is always needed and then other portions (profiles) of the specification are only used when needed for specific use cases/communities. The specification needs to all fit together and work as a whole for the composition of use cases but if I only want to exchange generic BOMs I would only need the core. If I want to exchange information about software or hardware I would want the profiles for software and/or hardware along with the core. If you want to exchange license information about software you would want the core, the software profile and the license profile. Similarly if you want to exchange provenance information about hardware or software you would add in the provenance profile to the core and the hardware or software profiles. In the Object Management Group this concept is captured by stating compliance points - subsets of the overall specification that can be claimed conformance with/support of. Hope that helped some, Bob Robert (Bob) Martin Sr. Software and Supply Chain Assurance Principal Eng. Cross Cutting Solutions and Innovation Dept Cyber Solutions Innovation Center MITRE Labs MITRE Corporation 781-271-3001o 781-424-4095c On 4/1/21 2:46 PM, Henk Birkholz wrote: > Hi all, > > I was blocked from attending the last meeting and I really like the > activity on the list here right now. > > Please bear with me while I might open yet another potential can of > worms right now (only on the naming level, not on the concept level). > > Am I mistaken in this context when I think of a profile literally to > be a subset of a model? I think I read somewhere in the replies that a > profile will add new things. That was quite surprising to me as I > would think of that as an extension (sometimes named an augment). A > profile specification can go hand-in-hand with an extension > specification, of course. But to not potentially violate a principle > of least surprise here, I'd like to throw a proposal into the ring > here that is not to mix up these two kinds of "follow-up" specifications. > > Viele Grüße, > > Henk > > On 01.04.21 20:33, Gary O'Neall wrote: >> Responses to both William and Alexios below. >> >> I like the way Alexios framed up the conversation. Perhaps we should >> revisit what changes are allowed, being quite specific this time >> around. Once we agree on that, we can go back to the discussion on >> how we represent those changes in the information model, the >> serialization schemas, and the spec documentation. >> >> Gary >> >> *From:* [email protected] <[email protected]> *On >> Behalf Of *William Bartholomew via lists.spdx.org >> *Sent:* Thursday, April 1, 2021 9:03 AM >> *To:* [email protected] >> *Subject:* Re: [spdx-tech] interactions between profiles >> >> I know I missed the beginning of the call so apologies if I'm >> re-opening a can of worms, but I'm a big fan of immutability, what >> would the world look like if we only supported create (I'd include >> extending an enum in this category)? What wouldn't be possible? For >> the things that aren't possible can we come up with a way to make >> them possible with create instead of modify? >> >> William >> >> */[G.O.] I think there is a number of use cases where changing the >> cardinality of field is required. An example pointed out on the call >> was version. Currently it is optional, but in a security profile or >> integrity profile it may be required. On the call, we did discuss >> the version example in depth and explored creating a separate Field >> just for the profile – but that got really messy./* >> >> */Another consideration is that supporting “create” at one level >> implies “modifiy” at another. For example, creating a new enum value >> modifies the enum restrictions in the schema (or the enum class)./* >> >> */One way to keep the base profile classes immutable, is to subclass >> them in the profiles. However, there we ran into the multiple >> inheritance problem described below./* >> >> */To put some context around these discussions, on the call we >> arrived at the problem statement and options after trying to figure >> out how to map the spec document to our serialization schemas that we >> currently support for the SPDX spec. On the call, we used the JSON >> Schema >> <https://github.com/spdx/spdx-spec/blob/development/v2.2.1/schemas/sp >> dx-schema.json> as an example since many of the participants are more >> familiar with JSON than RDF. This is a bit different and more >> detailed than working through the information model. The problem >> comes when we want to support an SPDX document that supports more >> than one profile (e.g. both defects/security and licensing). This is >> where the multiple inheritance problem came in. If in the profiles >> we subclass every class that we modify (e.g. we want to change >> package version from optional to mandatory for security and make a >> required copyright field for licensing), then there would be 2 >> subclasses of package for each file. Then when we wanted to >> represent this in a single schema file, we’re trying to inherit from >> 2 classes – the subclass which modifies the package for the license >> profile and the subclass that modifies the package for the security >> related profile./* >> >> On 4/1/21 8:54 AM, Alexios Zavras wrote: >> >> Hi all, >> >> Following the extremely interesting and intellectually >> stimulating >> discussion on the SPDX Tech call on Tuesday, I thought I'd try >> and >> list the interactions between profiles that may exist. These gave >> us >> some head-scratching moments when we tried to model them. >> >> We all understand that, if we are going to have a number of >> profiles, each one of them will include some new information (for >> example, new fields). It may also affect some of the information >> defined outside this profile (for example, making a field >> mandatory). >> >> In an effort to “formalize” things, I'll be using abstract terms >> like Object, Field, and Type -- I hope we all understand the >> general >> meaning, even though our specification is not using these terms. >> >> */[G.O.] I’m assuming Object is equivalent to Class for the >> purposes >> of our discussion – let me know if I’m wrong on this./* >> >> So, a profile may do one or more of the following: >> >> [CREATE] >> >> 1. define new Fields >> >> 2. define new Types (used in new Fields) >> >> 3. define new Objects, with included Fields of certain Types >> >> [MODIFY] >> >> 4. add new Fields (with their Types) to Objects defined elsewhere >> >> 5. change the cardinality of Fields defined elsewhere (and thus >> change optional/mandatory status) >> >> 6. extend an Enum in a Type defined elsewhere, adding more >> alternatives (typical case: adding more Relationship types) >> >> All these were mentioned during the call. >> >> I assume removing/deleting Fields or Objects is not possible >> (right?). What about: >> >> 7. restrict an Enum in a Type defined elsewhere, removing some >> alternatives ? >> >> As an example, could a profile introduce something like a "Secure >> Checksum" idea that says that FileCheksum may NOT be of MD2 type? >> >> */[G.O.] I hope not. For the example, I can think of some other >> approaches which would fit into the Modify and Create category (e.g. >> create a new field SecureChecksum or have a required enum value >> which is a subset of all allowed values)./* >> >> */Once we agree on the types of changes allowed in a profile, we >> can >> analyze possible conflicts between the profiles. If we restrict >> changes to the add and modify categories above, I can only think >> of >> a small set of conflicts (e.g. 2 profiles choose the same Field >> name >> with different types./* >> >> Hope this helps show what we’re dealing with. >> >> -- zvr >> >> Intel Deutschland GmbH >> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany >> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> >> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany >> Doon >> Silva >> Chairperson of the Supervisory Board: Nicole Lau >> Registered Office: Munich >> Commercial Register: Amtsgericht Muenchen HRB 186928 >> >> > > > > > > . Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4026): https://lists.spdx.org/g/Spdx-tech/message/4026 Mute This Topic: https://lists.spdx.org/mt/81785860/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
