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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-users message

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

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

-abstract-
Politics is saying what people want to hear
Business is saying people what you're offering is what they want/need
Science is giving people what they need (and maybe they didn't know they need)


On Tuesday, 24 November 2015, Shawn Riley <shawn.p.riley@gmail.com> wrote:

I'm glad that both the JSON camp and the JSON-LD camp will be given "the chance to make their argument with specific, concrete examples" before we vote.

On Nov 23, 2015 8:35 PM, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
I would love nothing more than to have so much demand for STIX via JSON-LD or Cap-n-Proto that we have to rev the specs to support it.  That would make me so happy.  

Let's do this in steps with a vision to become the best and most widely used solution for CTI.  

Having to rev the spec to support higher level ontologies or high throughput would be an amazing problem to have.  But first, we need vendor buy in.  Once we get that, we can move to the next level.

Bret 

Sent from my Commodore 64

On Nov 23, 2015, at 5:40 PM, Shawn Riley <shawn.p.riley@gmail.com> wrote:

I'm hopeful that developers will be gaining more experience with JSON-LD since Google announced their support for JSON-LD in January of this year.



More importantly, JSON-LD already has cross-platform availability:

_javascript_

Python

PHP

Ruby

Java

C#

Go


On Mon, Nov 23, 2015 at 7:29 PM, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
I fully understand what JSON-LD is.  I just do not believe it will help us drive adoption.  In fact I think it will hinder adoption.  

I have yet to see or hear any network product / security product / open source security tool developer ask for JSON-LD.  What I do hear, as I walk the floor at RSA and Blackhat is every CTO and product manager asking "when are we going to support JSON".

Further, it is not really essential to convince this group on what JSON-LD is, it is however, necessary to convince and train every developer and product manager on the planet.  And I do not see that happening.  

Analyst use products built by vendors.  Those vendors are asking for JSON.  When they start asking for JSON-LD, then I am sure we will rev the standards to support it.   If we do not get adoption then all of this is for not.  

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 
On Nov 23, 2015, at 16:42, Shawn Riley <shawn.p.riley@GMAIL.COM> wrote:

As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <terry@soltra.com> wrote:
+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>




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