Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)

[Shawn Riley <shawn.p.riley@gmail.com>]

By the way, data.gov has 7046 data sets available in RDF. Most are available in multiple formats (CSV, RDF, JSON, XML). http://catalog.data.gov/dataset?res_format=RDF&_res_format_limit=0#sec-tags

If you want to play with RDF data for yourself, select a data set in RDF, if you are at a desktop and don't want to set up any code or libraries use http://rdf-translator.appspot.com/  

You can copy and paste the RDF into the 'input field' box and select which RDF serialization format you want to see the data in. This way you can see how RDF data looks at RDF/JSON-LD, RDF/XML, RDF XML (pretty), RDFa, N-Triples, N3, etc. 

You could then look at the same data in native JSON (available on data.gov) or RDF in it's various serialization formats (via data.gov and the translator).

Thought this might help until we get some STIX specific examples shared out. 

On Wed, Oct 7, 2015 at 11:58 AM, Jordan, Bret <bret.jordan@bluecoat.com> wrote:

Yes, for professional modelers and people that work in RDF every day, this would seem like the best thing to do.  You are using advanced tools, software packages and libraries that can consume anything as long as it is RDF.  

The problem is, most of the developers that we need to recruit to write tools and software to work with STIX are not professional modelers and RDF people.  They work in PHP and _javascript_, or in Objective-C, Android-Java, C++, Python, Perl, Ruby etc.  They need to read in a blob of data over the wire, say JSON.  Stick that in to memory somewhere.  Then unmarshal that in to a struct or series of maps/dictionaries and then do something with it.  

Further, most vendors that build security products or networking products use a PHP interface or Java interface with a ton of JSON and a REST API.  Lets not make things hard for them.  We need to recruit them.  We need to get them on board. 

Speaking from my past experience in start-ups.  If the technology is outside of the development stack, and it is a checkbox feature, then it will never get done.  We need this to be so simple and easy that everyone says "why would I NOT do this, lets just do it make it happen".  At RSA and Blackhat I talked with a lot of startups that said, "if you would only do JSON we could adopt this".  I talked with Facebook and they said if we could do JSON, they could support it natively in their solution. 

If we want to win, lets make it easy for organizations to understand and use.

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 Oct 7, 2015, at 09:47, Cory Casanave <cory-c@modeldriven.com> wrote:

For “RDF people”, this is a non-issue. You call a library to read or write your data and it takes care of serialization. You will be able to accept data in any of the formats and not care, you deal with the RDF API and local language objects. This is why my specific knowledge of JSON-LD is minimal, it is just something a library takes care of.

 

I do understand the perspective of “_javascript_ people” who need to deal with the data in a specific syntax and don’t want to know about RDF.

In that the RDF people should not care and JSON people care a bunch it would seem a good idea to have a default serialization in JSON.

 

(I said I would shut up and I’m not doing well)

 

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Shawn Riley
Sent: Wednesday, October 07, 2015 11:40 AM
To: Jordan, Bret
Cc: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)

 

Help me understand this statement "Allowing people to send "RDF/JSON-LD (Hardback), RDF/XML (Paperback), RDF/Turtle (Amazon Kindle), RDF/N-Triples " will just mean this effort will be an epic failure and no one will be able to talk to each other" 

 

Since all of those formats are RDF serializations, there are existing translators today that can convert RDF/JSON-LD to RDF/XML or RDF/Turtle or any other RDF/serialization format. This should increase adoption without forcing everyone to only use JSON. 

 

 

 

On Wed, Oct 7, 2015 at 11:17 AM, Jordan, Bret <bret.jordan@bluecoat.com> wrote:

You said: 

 

"I have to believe that giving the community a choice of valid RDF based serialization formats (Hardback, Paperback, Amazon Kindle, Apple iPad, etc) will increase adoption faster than locking everyone into one serialization format like Hardback (JSON) or Paperback (XML). "

 

This is not a good idea IMO.  We need a default on the wire solution that every one uses.  Eric mentioned that in his email earlier today.   Allowing people to send "RDF/JSON-LD (Hardback), RDF/XML (Paperback), RDF/Turtle (Amazon Kindle), RDF/N-Triples " will just mean this effort will be an epic failure and no one will be able to talk to each other.  

 

Remember developers will be working with the on-the-wire formats.  I do not like the hand waving of, oh the software will figure it out.  No, developers need to write the software that consumes it and does something with it.  Further, given that most people in this community have a hard time with understanding RDF and why it is needed, that goes to show that most developers in the wild probably also have a hard time understanding it.  The average open source, web application, and APP developers want JSON, plain and simple and probably do not know how to even work with RDF.  The more complicated we make this, the more esoteric solutions we use, the less likely they will code to it.  

 

I am a huge proponent of UML models with JSON schema bindings.  Very simple, very easy to understand, and very easy to use.  The cost of entry for people to get started is minimal.  If we want adoption, we need things to be simple and easy.  I do not view RDF as a solution for STIX as the complexity cost will drive people away.  UML is a great middle ground, average developers and companies and vendors can look at the UML models and quickly and easily understand what is going on and what they need to do in their products / software / solutions.  Then if the data over the wire is in JSON schema, they can quickly and easily put this in to use in their PHP applications, their JAVA applications, their C++ applications, etc...

 

 

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 Oct 7, 2015, at 08:04, Shawn Riley <shawn.p.riley@GMAIL.COM> wrote:

 

If you remember the XML vs RDF analogy of A Christmas Carol from Cambridge Semantics, http://www.cambridgesemantics.com/semantic-university/rdf-vs-xml, this example might help in better understanding the JSON vs RDF/JSON-LD choice.

 

If STIX reports were Books.

 

A STIX JSONSchema Book Store offers STIX books in JSON (Hardback)

 

A STIX RDF/OWL Book Store offers STIX Books in multiple RDF serializations. RDF/JSON-LD (Hardback), RDF/XML (Paperback), RDF/Turtle (Amazon Kindle), RDF/N-Triples (Apple iPad), etc. 

 

The content of the STIX books from the STIX RDF/OWL Book Store is the same regardless of the on the wire serialization (RDF/JSON-LD, RDF/XML, etc) with dozens of tools already available that can convert between RDF serialization formats in case you want to read your book in another RDF serialization.

 

I have to believe that giving the community a choice of valid RDF based serialization formats (Hardback, Paperback, Amazon Kindle, Apple iPad, etc) will increase adoption faster than locking everyone into one serialization format like Hardback (JSON) or Paperback (XML).