|I still think we should figure out what we need before we figure out what we are going to do.|
Of course, IMHO it is hopelessly complicated, but it is the foundation for SNMP, LDAP, X.400, yadda, yadda, so you cannot claim no one uses it.
My point is not that I am advocating for ASN.1. My point is we should be agreed on what we need, beyond “something that uses JSON” and “not XML” before we make a choice.
I’ve taken a step back from this conversation because I think we’re starting to have a circular conversation among the people that are discussing this, but fwiw I still strongly agree with Jason and Bret that JSON (with JSON schema to validate) is the best approach.
That said I do think it’s worth evaluating Cory’s proposal as a potential compromise. Cory, are you going to be looking into it? It seems interesting, would just want to see a little more testing to verify that it will actually work and to see what it means for the structure of the JSON.
Along the lines of stopping the circular conversation, maybe it would be a good time to pause to wait for new voices? Vendors?
[I moved this to the CTI list, my reading of the rules says that as substantive spec discussion it should happen there. If I’m wrong we can move it back.]
So this is the plot developing in my mind…
We define a logical data model in UML (big surprise), from this we generate BOTH a RDF/JSON-LD schema with some structural annotations (this is being called frames by the JSON-LD camp) as well as a JSON-Schema. A valid CTI document will validate against both. A JSON-centric developer sees a structure, the semantic web centric developer sees RDF. The JSON-Schema will include the “context” properties that JSON-LD uses but these may not be used by the JSON centric developers. Thus both paradigms can be supported for the same wire format. As the market develops we will see where there is take-up and value. Other than the extra context properties I don’t think there would be any runtime overhead. The STIX API (which also could be generated) would, of course, fully support this format.
Cost: There would be some development required to generate these dual specifications from UML, but the effort would not be large and only the CTI team would need the capability since it would produce the normative CTI artifacts. There may also need to be some tweaking of RDF sterilizers to support this specific serialization format, but again, not a big deal. I suspect other groups may also find this capability interesting.
Of course, this would all have to be proven out – but I don’t see any major problems. There would be a couple of constraints on the RDF, but no deal killers.
I'll echo this and add onto it as well, the other much larger consideration here is simply the realities of software development. Every new format that exists in the wild, is therefore another format that you need to add support for to your tools if you want to have a workable ecosystem where tools can talk to each-other. It's also another format that needs to be developed, tested, and certified, against all of those various other tools, both internally and externally.
It doesn't matter if there are pre-existing translation libraries available for this translation. Libraries like that only reduce a tiny amount of the overall workload. The marshalling and de-marshalling of data is only one piece of the work effort... arguably, its the smaller piece.
In fact, with every new wire format, the integration work required will increase in a geometric fashion.
This is why it is so important to have "one true" wire format codified as a standard.
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<image001.gif>"Jordan, Bret" ---2015/10/07 12:58:58 PM---Yes, for professional modelers and people that work in RDF every day, this would seem like the best
From: "Jordan, Bret" <firstname.lastname@example.org>
To: Cory Casanave <email@example.com>
Cc: Shawn Riley <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>
Date: 2015/10/07 12:58 PM
Subject: Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)
Sent by: <email@example.com>
Thanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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."
Sent: Wednesday, October 07, 2015 11:40 AM
To: Jordan, Bret
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 <firstname.lastname@example.org> 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,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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).
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]