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
Remove abstract base types for "top-level" objects #386
Comments
💯 (ie, awesome!) |
I agree completely. Thank you @sbarnum |
I would not consider a Sighting to be a fact. The proposals and underlying model are based on the above semantics. |
Did we ever reach a consensus on how to "fix" the inherent semantic confusion between Sighting <==> Observation (I've read every one of your explanations over the years, and they always make sense, yet I (and I expect others) still confuse the two. 🤔 It's like "Tornado Warning" and "Tornado Watch", except confusing this can get you killed 😁 Sighting = PatternDetection |
Perhaps, once again, we should step back and look at how people need or want to use this thing. In my view, a Sighting is an assertion that you saw something. When someone published an Indicator and says that this file hash is bad, then you want some way of saying, "yes I saw that too", or "I saw that 100 times in the past 24 hours". |
This issue was discussed extensively. No normative text is required as these are simply things that will not exist in 2.0 |
STIX 1.2.1 contains a set of abstract base types for each "top-level" construct except Observable (which leverages CybOX directly). Each of the "top-level" objects derive from these abstract base types and the abstract base types are leveraged wherever relationships to the "top-level" object concepts are needed.
These abstract base types were included in STIX for 3 reasons:
Propose removing these abstract base types as unnecessary due to the following:
The text was updated successfully, but these errors were encountered: