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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: RE: [cti-stix] RE: New property names for previous label properties


I agree with John-Mark and suggest we use "object_types" for the categorizations/types, and use “labels” for user-defined tagging.
Basically joining of 1 and 3 but using "object_types" rather than "classifications".

-Marlon

-----Original Message-----
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> On Behalf Of John-Mark Gurney
Sent: Friday, May 18, 2018 3:47 PM
To: Wunder, John A. <jwunder@mitre.org>
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] RE: New property names for previous label properties

Wunder, John A. wrote this message on Thu, May 17, 2018 at 17:31 +0000:
> I wanted to bump this discussion on the “labels” topic being tracked as issue 37 [1]. We discussed it on the May 8 working call [2] but unfortunately still don’t seem to be at consensus on this topic. It’s a blocker for releasing the STIX 2.1 CSD so getting to a resolution is important.
> 
> Along those lines, one other option came up on Slack recently: while we typically avoid using “classification” because of connotations for the government community (and those supporting them), the feeling maybe we should reconsider it. Given that new option, to restate the proposals:
> 
> 
>   1.  *_types (indicator_types, malware_types, threat_actor_types, etc.) for the categorizations/types, and use “labels” for user-defined tagging
>   2.  Keep these values from the vocab in “labels” (as they are now), add a new property called “tags” to capture the user-defined tagging
>   3.  Use the name “classifications” for the categorizations/types, 
> and use “labels” for user-defined tagging
> 
> We could really use more input on these, in particular if you’re now open to different options or have not yet weighed in. I’d suggest we just list an order of preference to see if maybe there’s a compromise that gets us somewhere. My order of preference is 1, 3, 2 but any of them seem fine.

I'll say that I'm a bit worried we are working so hard to make it so people don't have to read the specification and normative text that we spend so much time writing.  Yes, naming things is hard.  If you don't read the standard/spec, and make a mistake, that's on you, not on us.
There are lots of names that overlap, and mean different things in different fields of study.  We also have the advantage that the standard is free and open to everyone.  So the excuse that I didn't have a copy of the standard because it costs $10k+, so I couldn't have read it is gone.  Now it's only that I was too lazy to read it.  If you don't understand the standard/spec, then yes, it's out problem and we need to fix it.

That said, what ever name we pick, we can make the computers use, BUT:

I personally perfer the same name to be used for categorization/types, because then we can make the names reserved, and custom objects can use them, and tools can automatically handle them, etc.  If we go w/ 1, then we have to write rules on how to convert the object type to the *_types name, or someone has to create a hard coded table of all of these, etc. and we completely miss out on the ability to use the field on custom objects.

What the actual name we pick, I don't have a strong preference, I just prefer we use the same name for all objects that need it.  Also, a large part of this should be abstracted out by the UI.  If we have products that let people author bad data, then it's going to be a problem no matter what we as the writers do.

--
John-Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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