Remove abstract base types for "top-level" objects

[sbarnum]

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:

1. to support the potential desire of some user to leverage a completely different implementation for one of the "top-level" concepts rather than the STIX default implementation (e.g. IODEF instead of STIX Incident).
2. to support the potential desire of some user to leverage a specialized derivation of one of the default STIX implementations of the "top-level" concepts (e.g. the secret squirrel community wishing to leverage a Threat Actor++ implementation with some domain specific properties unique to them).
3. to enable loose coupling of the various "top-level" default implementations in the very explicit domain of XSD Schema serialization

Propose removing these abstract base types as unnecessary due to the following:

• reason stix_common.xsd: ActivityType/Date_Time doesn't have a type #1 above has never proven out to be likely and would be serious ill-advised anyway
• reason TTP: Attack_Pattern, Malware_Instance, Exploit and Infrastructure should have @id & @idref fields #2 above could still be accomplished without the abstract base types by extending the concrete "top-level" objects themselves
• this sort of serialization-specific limitation could and likely should be conveyed as part of a serialization binding spec rather than an integral part of the implementation independent language model

[johnwunder]

💯

(ie, awesome!)

[jordan2175]

I agree completely. Thank you @sbarnum

[packet-rat]

Nuanced Question: Isn't a "Sighting" a "Fact" and not an "Assertion" per se? Yes, an assertion can be based on a "Fact". But it can also be based on a "Belief". Shouldn't we discriminate between "Facts" and "Beliefs"?

[sbarnum]

I would not consider a Sighting to be a fact.
An Observation is a fact. "I saw this"
A Sighting is an assertion that something that was seen matches a given pattern. "I saw something that looks like what I was told to look for"
I would suggest that there is uncertainty involved in asserting that such a match exists.

The proposals and underlying model are based on the above semantics.

[packet-rat]

☺️ Darn...you'd think we would have this whole "Sighting", "Observation", "Observable" thing sorted out by now.

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
Sighting = DetectedPattern

[jordan2175]

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".

[sbarnum]

This issue was discussed extensively.
Consensus was asserted that the abstract base classes for the TLOs should be removed.
A one week comment period was opened 2/1-2/5 where no objections were raised to the consensus.
Consensus is now officially asserted as achieved.

No normative text is required as these are simply things that will not exist in 2.0