You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are going to be creating specifications/standards for interoperation. Terminology will be important and we will probably spend too much time arguing what certain words mean. I believe one important distinction we will need to make for each term is whether the spec contains a 'definition' or a 'description'. It seems nickpicky but doing this correctly may make lawyers happier and may make the process go faster.
A definition is 'the exact meaning of a word' and a description is less exact and can change person to person.
One example where this was important was STIX use of the label 'terrorist'. We did NOT "define" terrorist (political hot potato as well as context sensitive - Ethan Allan was a patriot in the American Revolution but he was a terrorist from the British viewpoint). STIX 'describes' terrorist. It's a label that an analyst (human or virtual) can use and convey that label in a STIX message. In STIX we don't define what a terrorist is. That's up to analyst in the context of their environment. We do include a description and are careful to use the word description not definition (and it's not in the definitions section).
We will need to decide on terms like "end of support' whether we 'define it' (we get everyone to agree on one definition that will apply to everyone in all situations or 'describe it' - ie we include words but they are nonbinding and it is between the sender and the receiver to agree on a definition for their interopration, but a different pair may use a different definition. Note the JSON won't care either way - it will contain the same content.
Note we can even change our minds. E.g. when we run into a terminology roadblock trying to define a label, we make it a description and get this version of the spec approved. If at a future time, we manage to get agreement on a definition, we update the spec. it would even be a non-breaking change as the interface wouldn't change - just the words in the spec on the use of that particular label.
The text was updated successfully, but these errors were encountered:
We are going to be creating specifications/standards for interoperation. Terminology will be important and we will probably spend too much time arguing what certain words mean. I believe one important distinction we will need to make for each term is whether the spec contains a 'definition' or a 'description'. It seems nickpicky but doing this correctly may make lawyers happier and may make the process go faster.
A definition is 'the exact meaning of a word' and a description is less exact and can change person to person.
One example where this was important was STIX use of the label 'terrorist'. We did NOT "define" terrorist (political hot potato as well as context sensitive - Ethan Allan was a patriot in the American Revolution but he was a terrorist from the British viewpoint). STIX 'describes' terrorist. It's a label that an analyst (human or virtual) can use and convey that label in a STIX message. In STIX we don't define what a terrorist is. That's up to analyst in the context of their environment. We do include a description and are careful to use the word description not definition (and it's not in the definitions section).
We will need to decide on terms like "end of support' whether we 'define it' (we get everyone to agree on one definition that will apply to everyone in all situations or 'describe it' - ie we include words but they are nonbinding and it is between the sender and the receiver to agree on a definition for their interopration, but a different pair may use a different definition. Note the JSON won't care either way - it will contain the same content.
Note we can even change our minds. E.g. when we run into a terminology roadblock trying to define a label, we make it a description and get this version of the spec approved. If at a future time, we manage to get agreement on a definition, we update the spec. it would even be a non-breaking change as the interface wouldn't change - just the words in the spec on the use of that particular label.
The text was updated successfully, but these errors were encountered: