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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] Detailed sub-issues for the topic of refactoring "sources"


My proposed answers are inline below

From: <cti@lists.oasis-open.org> on behalf of "Barnum, Sean D." <sbarnum@mitre.org>
Date: Tuesday, February 9, 2016 at 3:36 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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.


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