OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: some comments on Stix-2.1

To recap some of my thoughts regarding Stix-2.1:

"description" (optional) should be part of the common properties.
"name" (required) should be part of the common properties.
"labels" which is part of the common properties should either be required or optional, not both.

With respect to 
Observable EmailMessage, I think there is no need to have "is_multipart" and "body_multipart”. Make "body" a dictionary of "mime-part-type" (string) and "body_part" (string).

Regarding the custom properties, I would rather have all custom properties in a dedicated specified named attribute, e.g. "custom" (optional). So we know where they are, rather than ad-hock mixed-in with all the other attributes names.

The SROs carry some embedded links (e.g. created_by_ref, object_marking_refs, observed_data_refs). In graph databases such as Neo4j (and probably all others), a relation is from a source node to a target node, it cannot itself have relations to other nodes or relations. So one implementation option (that I chose) to cater for this, is to make an artificial (Relationship/Sighting) node object that those embedded links can refer to. Just a thought, but maybe it would be better to specify an SRO node with most of the attributes and leave the relation itself to be from a source to a target node with just the required attributes.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]