ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Use CaseSDO ConsiderationsEmb ConsiderationsSummaryBias
2
Specifying location attributeslocation attributes (lat/long, civic, region…etc) are the same whether embedded or SDOlocation attributes (lat/long, civic, region…etc) are the same whether embedded or SDONo differenceSAME
3
Managing data markings separatelydata markings can be applied to either but are simpler in the case of SDO as object-level marking can be used instead of attribute-level marking in the case of embedded locationWith Emb location then fine-grained data markings would have to be used.Easier with SDOSDOrellerreller: I think this is probably inconsequential, and I don't know what makes it easier. There is less text, but I'm not sure of the metric for easier.
4
Independent management of locationlocation object will have an ID, timestamps associated with creation, modification and revocationTimestamps will be associated with the intel the location references in non-SDO case, therefore if a provider wanted to provide separate location object then they would either update the object with location and version the object or create a duplicate object (effectively) and set the location and reference the original objectWill require more work with Emb if independent location is a use case importantSDOrellerreller: Can you further explain the use case? I don't understand who is trying to do what. For a use case I'm expecting to see this actor/role is trying to do this action. I don't know who is trying to do independent management of location and what that means exactly.
5
Defining location across objectsWith SDO a single location can be shared across multiple intel objects.With Embedded it would require location object to be copied into all objectsWill be more objects in the case of location SDO as multiple relns will have to be created to connect separate intel to single location vs just copying the objectEMB
6
Specifying only region or country (coarse-grained location) across multiple objectsWith SDO create one object with those attributes and then associated via relationship to each object.With Embedded assign the location properties and then copy across all objectsWill be more objects in the case of location SDO as multiple relns will have to be created to connect separate intel to single location vs just copying the objectEMB
7
Updating location of one specific intel object (with same permissions)SDO: If already assigned a location and that location is shared with other intel objects that are not changing then a new location object is created and then related to the intel objectEmb: Updates the attributes of the intel object and versions the objectAbout the same amount of work in either case if permissions to modify are the same. If permissions different then more complx in the case of embedded as entire intel object has to be copied to modify the location whereas in the SDO case a new location SDO gets created and the reln is updated not the entire intel objectEMB
8
Updating location of multiple intel objects (with same permissions)SDO: If already assigned a location and that location is shared with other intel objects then a new location object is created and then related to the intel objects being updatedEmb: Updates the attributes of each intel object and versions each objectAbout the same amount of work in either case if permissions to modify are the same. If permissions different then more complx in the case of embedded as entire intel object has to be copied to modify the location whereas in the SDO case a new location SDO gets created and the reln is updated not the entire intel objectSAME
9
Updating location of one specific intel object (with different permissions, permission for location to be created but not revoke or modify existing intel object or location object or reln connecting them together)SDO: If already assigned a location and that location is shared with other intel objects that are not changing then a new location object is created and then related to the intel object. The existing reln to the original location will not be able to be deleted.Emb: A new intel object is created with new location. Existing object and location will existOnly new location object, no new intel objects in SDO case wherease with emb case the new intel objects have to be created too which may not be appropriate given that the org is only really providing the location not the intel itselfSDO
10
Updating location of multiple specific intel object (with different permissions, permission for location to be created but not revoke or modify existing intel object or location object or reln connecting them together)SDO: If already assigned a location and that location is shared with other intel objects that are not changing then a new location object is created and then related to the multiple intel objects. The existing reln to the original location will not be able to be deleted.Emb: Multiple new intel object are created with new locations. Existing objects and locations will existOnly new location objects, no new intel objects in SDO case wherease with emb case the new intel objects have to be created too which may not be appropriate given that the org is only really providing the location not the intel itselfSDO
11
Changing the location structure later on does not require significant modification to all STIX objectsSDO: A change to a location SDO object would be possible provided the permissions to do so to the original location. Similar to modification use cases above regarding permissionsEmb: Would require permission to modify location properties on the intel object Provided permissions to do so in both SDO/Emb cases then it would be modifying an SDO set of properties vs Intel object location props.Same
12
I need to use location on any SDO, not just the ones that have been pre-ordained at design time (aka “now”).SDO: Ability to define location and then associate that location SDO with any object will be possible with the generic relationships that existEmb: Would require location property object (and sub-attributes) defined as a core property inherited by all SDO objectsWith SDO allows location to be associated with intel after the intel SDO was created whereas embedded would require the location to be updated on the Embedded intel object. Permission issues permitting those actions.Slightly in favor of SDO due to indirect relationship of location to intel object
13
Encode multiple locations for the same intel object simultaneouslySDO: Define relns from different locations to the same intel object with different relkns such as registered_from and used_fromEmb: Would require new scheme to allow multiple location objects per intel object with named key value that identifies what this location is associated with the intel object forMore consistent approach using SDOSDO
14
Analyst creates new SDO and sets locationIf existing location is known then a relationship is created between the new intel object and existing location object. If the location is new or the creator prefers to associate their own location info with the intel object then they create both the intel object, the location object and associate the 2 together using a relationshipSimply insert the location information into the desired fieldIf Relationship solution is to always create a new Location object then it's about the same. More text in Relationship case, but I'm not sure that we care about that metric.Emb
15
Analyst wants to compare two SDOs and determine if they have the same location.In SDO case if they share the same location relationship then a comparison of the relationship pointer is enough. If the location object is the 'same' content but in different location objects then a content comparison of the location objects themselves would also be requiredUse normative rules to parse the locations and compare for equality.In the case of SDO there are 2 choices for comparison (comparison of the reference itself -> fastest, comparison of the value where the reference has to be found to do that comparison). For value/content comparison then its the same for SDO or EmbSlightly faster for reference comparison in SDO case if same location object is referenced otherwise same across both approaches
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100