Create 2024-08-09.md

safety/2024-08-09.md

@@ -0,0 +1,32 @@
+# SPDX FuSa Meeting 2024-08-09
+## Attendees
+* Steven Carbno
+* Nicole Pappler
+* Chuck Wolber
+* Alfred Strauch
+* Ryan Brooks
+* Nikhil Kumar
+* Kate Stewart
+
+##Agenda
+- Continue discussion of modeling
+
+## Notes
+   - Discussion of how should roles around a relationship be modeled. 
+  - Should we handle roles as relationships?  "fromRole:"   "toRole:"   for a single instance of a relationship.  Additional optional in relationship class. 
+  - Action may let us model this in part?   Artifacts are event at point in time. 
+  - Challenge with action is scope of issue - how deep to go with concept due to level of abstraction it supports.
+  - Role acts as definer. 
+  - Originated/Supplied by --> may be better handled by a role of relationship to action?
+  - Participant is performing a given a role in a relationship,  and may be performing a different role.
+
+- Should roles be enumerations or strings?    ideally enumeration. 
+   - should be more than for persons,  ie. program doing action. 
+   - For example test is verifier. 
+   - Further characterizing the metamodel to allow more details to be unambiguously defined.
+   - Consider "RoleScopedRelationship" class with the "fromRole" & "toRole" properties.    
+         - Consider fromRole/toRole as another classes with additional properties.   Beyond enumeration.
+   - Element collection is a more general case of this specific concept. 
+   - How should we look at constraining a role - 
+      - atomic;  characterize as learn about,  some 
+  - Should the realtionship type constraint the roles that can be used?  Likely yes.