-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to.md to reflect what min:0 means #623
Conversation
Min 0 allows producers to indicate that there are no known relationships of the given type. Signed-off-by: Kate Stewart <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kestewart - Very minor wording suggestion.
Fixes #527 |
Co-authored-by: Gary O'Neall <[email protected]>
Your wording suggestion looks good to me. Applied. @goneall - can you re-review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Discussed on the tech call. There was confusion as to the reason for this change. Team agreed it needs further discussion with @kestewart and @goneall |
This incomplete relationship approach seems very problematic as it makes it difficult for people to understand the intended semantics, does not really make sense to have a relationship with only one end, and will break any sort of graph semantic or structual analysis out there. It seems like a much cleaner approach to this would be to define two new Individuals of type Element (yeah, I know Element is supposed to be abstract but this seems like the first clear reason to maybe violate that):
In this way the appropriate Individual could simply be used as the value of the This is much more semantically clear in approach and in value, it does not violate graph semantics, and it would be valid under various approaches and technologies for graph semantic or structual analysis out there. |
@JPEWdev - can you please review Sean's comments, and weigh in here. Specifically in the 2.3 spec there is:
@goneall - do you want to weigh in on this? |
I (really) like Sean's proposal above with one caveat. I just merged PR #588 which created a |
I'd be in favor of keeping them as NONE & NOASSERTION at this point. NoneElement as a term may be confusing. |
@kestewart - do you think we should keep the current NoneLicense and NoAssertionLicense if we go with NONE and NOASSERTION? See PR #588 for context. |
@goneall - I'm fine with keeping NoneLicense & NoAssertionLicense, if that's what the legal team requested to use on License expressions. I can see it simplifying some things, but if it wasn't their request, let's just revert back to NONE & NOASSERTION as we have it in 2.3. |
Given that NoneLicense and NoAssertionLicense involve a type restriction to AnyLicenseInfo I think it makes sense to keep them as is with the "License" specific extensions in their names. |
Agree - @sbarnum - do you want to create a separate PR with the proposed solution? |
Note: new PR will need to be generated, with min to be updated to 1; and the NONE & NOASSERTION elements created. @sbarnum - can you take a pass at this PR, so Gary and I can review while traveling this week? |
Also, it should be noted that we have https:/spdx/spdx-3-model/blob/main/model/Core/Vocabularies/RelationshipCompleteness.md in the model already, and this should be factored into any changes so this doesn't accidentally overlap and cause confusion. |
@goneall After looking at RelationshipCompleteness while in the process of creating the PR I realized that noAssertion in RelationshipCompleteness has no overlap or conflict with NOASSERTION as a subclass of Element and used in the |
Consensus of the Feb 06, 2024 Tech call was to pursue approving and merging #629 to resolve this issue. It was discussed very briefly that there is a potential for confusion between the use of NOASSERTION in the |
Need to decide between this one and #629 |
Min 0 allows producers to indicate that there are no known relationships of the given type.
Signed-off-by: Kate Stewart [email protected]