RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

[Terry MacDonald <terry@soltra.com>]

+100 John.

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com 
 

-----Original Message-----
From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

I feel like I should weigh in on this since I put my name on the resolution and have spent some time looking into JSON-LD. Sorry for the length.

I can see the value in having RDF/OWL-based tools talk directly to each other. I don’t personally use those tools and don’t plan to start using those tools but I understand that others do and will want to use them with STIX.

At the same time, I think most people will use tools that are specifically developed for this domain. There will be python code or Java code or Ruby code behind them. These tools will be used by threat analysts and incident responders and CTOs to do their jobs. But, they will be coded by developers against the MTI specification of STIX.

The MTI format should optimize for the preponderance of usage, if possible making concessions for other approaches. The preponderance of usage is clearly in custom-developed tools and therefore the format should optimize for that. As I think the vote will show, these developers will want JSON (or XML or protobuf, but mostly JSON).

It’s true that JSON-LD is technically JSON and makes the RDF-based approach (to be honest) much more palatable. From my own investigations it does not go far enough. That said, if you’re on the fence you should wait to see what Sean, Shawn, Pat, and Cory produce. Maybe they got farther than I did and if so we should consider it. I know I would change my vote if it truly gets to the point where support JSON-LD is only a bit more work.

My last point…if you want to exchange RDF-based STIX data go ahead and do it! You can convert the UML into OWL and exchange that just like Cory is saying below. We could even standardize that as a non-MTI format and because everything is driven from the model you can losslessly convert.

Summary: let’s not burden the majority of people who are writing custom software. Developers are lazy and if the JSON-LD is even 10% more confusing or complicated than the regular JSON that can and will drive people away. The semantic tools will still be able to talk STIX with each other. With some minor massaging they can probably even consume data produced in “native” JSON. But let’s get this near-term win on simplicity and get a crapton of tools and data feeds out there supporting STIX.

John

> On Nov 23, 2015, at 4:32 PM, Cory Casanave <cory-c@modeldriven.com> wrote:
> 
> Re: Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?
> 
> JSON-LD, JSON-Schema, RDF Schema and XML Schema can all be produced, in a consistent form, from a well-structured UML model.
> 
> -Cory
> 
> -----Original Message-----
> From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Kirillov, Ivan A.
> Sent: Monday, November 23, 2015 2:50 PM
> To: Trey Darley; Shawn Riley
> Cc: cti-users@lists.oasis-open.org
> Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...
> 
> To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?
> 
> Regards,
> Ivan
> 
> 
> 
> 
> On 11/23/15, 4:06 AM, "Trey Darley" <cti-users@lists.oasis-open.org on behalf of trey@soltra.com> wrote:
> 
>> *Nor* is it the case that we are ruling out standardizing a JSON-LD 
>> CTI serialization schema *in future*. From the mail that went out
>> Friday:
>> 
>> <snip>
>> Likewise, the co-chairs recognize that there will be communities of 
>> interest requiring alternative serialization formats (XML, protobufs, 
>> JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to 
>> standardize these alternative representations to ensure 
>> interoperabilitity. However, that work effort lies in the future.
>> First we must complete the task at hand.
>> </snip>