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] Towards a better understanding of JSON-LD (Was: MTI Binding)


Very well put, Bret. This reflects our position as a security startup
100%.  Robust JSON bindings would greatly accelerate/facilitate adoption
of STIX into our stack. 


On 10/7/15 8:58 AM, Jordan, Bret wrote:
> 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
>> <mailto: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>
>> [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
>> <mailto: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 <mailto: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
>>     <mailto: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). 
>>
>

-- 
Chris Roblee
Director of Engineering
TruSTAR Technology
Mobile: +1 781 248 2828
OpenPGP key ID: 2C9D0D20




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