At this stage I think we should consider algorithms to handle identifiers
We should also think about moving to an adaptive model
On Thursday, 29 October 2015, Jerome Athias <> wrote:
could be discussed aggregates, non-determinism and asynchrony
2015-10-29 19:55 GMT+03:00 Jordan, Bret <>:
> The problem with de-dup is harvesting all of the nuggets of extra
> information that are tied to the references that you are about to throw
> away.
>
> Bret
>
> Sent from my Commodore 64
>
> On Oct 29, 2015, at 5:38 AM, Jerome Athias <> wrote:
>
> While not in an sql world (deduplication),
> The Relationship object will help
>
> On Thursday, 29 October 2015, Joep Gommers <> wrote:
>>
>> Dear All,
>>
>> I’d like to ask for your opinion.
>>
>> Use-case; many producers create intelligence with widely different content
>> (names/meta/context) for the same threat information. Additionally, many
>> producer don’t re-use or across producers we don’t re-use STIX IDs.
>> Therefor, the challenge of duplication is significant.
>>
>> While we’ve already have many non-STIX way of dealing with this at
>> EclecticIQ, I wonder if STIX versioning idioms aren’t a way to accomplish
>> part of this.
>>
>> Example;
>>
>> Before:
>> TTP A: Zeus, version 1 – namespace vendorA
>> TTP B: Zeus, version 1 – namespace vendorB
>> TTP C: Zeus, version 1 – namespace vendorC
>>
>> After:
>> TTP D: Zeus version 1 – my own namespace
>> Related TTPs
>> Supersedes IDREF TTP A version 1
>> Supersedes IDREF TTP B version 1
>> Supersedes IDREF TTP C version 1
>>
>> Basically telling my STIX authority that TTP A/B/C version 1 no longer
>> should be current and then TTP D version 1 (my analytic decision that my
>> Zeus is now all other Zeus) is actually analytically equal to the others?
>>
>> J-
