My proposed answers are inline below
From: <> on behalf of "Barnum, Sean D." <>
Date: Tuesday, February 9, 2016 at 3:36 PM
To: "" <>
Subject: [cti] Detailed sub-issues for the topic of refactoring "sources"
Here is the promised follow-up to the email with the concise high-level proposal statement for refactoring sources.
This is a stab at identifying several of the key sub-issues that need to be discussed/decided to make the proposed approach a practical reality.
More detailed sub-issues to be discussed/decided:
What should the structure of the Reference TLO look like?
Current proposal is three properties: (this addresses the “external_ids” issue
as well)
“reference_URL” (optional) - specifies a URL to the external reference
“external_identifier” (optional) - specifies an identifier for the external reference content
“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)
[sean]I support the current proposal described here
Use “created_by_ref” on each TLO as shorthand for “Producer” source relationships?
[sean]I do not believe that this is necessary but I do not object to it being included optionally in addition to explicit relationships.
Should “created_by_ref” shorthand and “Producer” Has Source relationship both be explicitly supported?
What if there is conflicting information?
[sean]Yes. For the time being I support both approaches being explicitly supported.
Should “created_by_ref” be optional or required?
[sean]Optional
Does leaving out both a created_by_ref and has_source relationship for an object imply anonymity?
[sean]No. I believe that there is a clear distinction between content with an unknown source and content with an explicitly anonymous source. I believe leaving out both a created_by_ref
and has_source relationship for an object should imply “unknown” source whereas “anonymous” source should be explicitly asserted with an “Anonymous” Identity object.
What values should be in the default vocabulary for the Roles property on Has Source relationships?
[sean]I would suggest the following list as a good starting point:
Producer
Analysis Originator
Codification Originator
Translator
Transformer
Anonymized
Reviewer
Transmitter
Derivation Resource
Should “Has Source” relationship support many-to-one capability to assert lots of STIX content has the same source in an efficient manner? Is the “efficiency” issue necessary to address at this time?
Basically this:
Relationship
ID = id-5
From = id-2, id-3, id-4
To = id-1
Nature = Has Source
Versus this:
Relationship
ID = id-5
From = id-2
To = id-1
Nature = Has Source
Relationship
ID = id-6
From = id-3
To = id-1
Nature = Has Source
Relationship
ID = id-7
From = id-4
To = id-1
Nature = Has Source
[sean]No. I do not believe that “efficiency” is a big enough issue for us to consider this in 2.0. It could always be added in future releases.