Where did this question come from?
Today Ryan Schultz tweeted this interesting question :
What's the HTML equivalent in the AEC industry?— Ryan Schultz (@theoryshaw) December 12, 2014
Stefan Boeyens was first to reply :
@theoryshaw should be #ifc but fear it's #dwg— Stefan Boeykens (@stefkeB) December 12, 2014
My short answer & follow up question :
@stefkeB @theoryshaw The HTML of the AEC industry IMO is HTML. But what is the JSON of the AEC industry?— Hans Kristian Grani (@hkgrani) December 12, 2014
I will in this post elaborate on my reply and thoughts on the subject.
Why do I think HTML is the HTML of the AEC industry?
HTML in the AEC industry is used the same way as in other industries. It is the published content for websites and product catalogs. It is also the basis for collaborative platforms for document control, bid management, design collaboration etc.
And HTML is evolving in a good way for the AEC industry. We can now embed vector graphics, 3d models, videos, sound and real-time-feeds without the need for plugins. The old contendors (flex, silverlight etc) have lost and we do not need java applets or flash plugins anymore.
What's even better - with the advances in web components we can now/soon extend HTML to fit the needs of the AEC domain.
The only alternatives to HTML today are native apps.
What about DWG and IFC?
For me DWG is the DOC/XLS of our industry, and IFC is the ODF of the industry. DWG/RVT are the leading proprietary formats and IFC is the open alternatve.
IFC the data model is evolving as a suitable domain model for lifecycle BIM and industry collaboration. However I see IFC the file format as a data interchange format - best suited for transferring "whole" sub-models between applications, users and phases.
To fully "web-enable" the AEC industry we need a format more suited at the data/api layer to support run-time in domain applications. The domain model can be IFC, but the format must be better suited for the web allowing better integration into both the frond and back-end of data-sharing applications, smaller file size and easier chunking and mashup-possibility.
Simple ifcXML, BIM Collaboration Format (BCF) and COBieLite are examples of initiatives to move in this direction. The reasoning behind these efforts are good but I just cannot help thinking about the parable of the frog and the scorpion. Its just not is XMLs nature to be easy, developer friendly and efficient. (To be fair to BCF check the ending of the post)
So what's the JSON of the AEC industry then, or rather what will it be?
To move quick and reap the benifits of the whole web-community we should embrace the winning standards, file formats and models for data-interchange. Industry specifics should be handled at a schema/ domain model level.
As stated above I do not think there is "a JSON" of the AEC industry yet. When it arrives I predict it will be either a domain specific JSON schema, RFD or a combination of both.
Below is a simle google trends analysis comparing XML, JSON and RDF. I will leave it here for now but will continue the discussion in the future. Stay tuned.
There is a BCF restful JSON-based API in the making under the BuildingSMART organization with Ryan Schultz as one of the contributors (which should bring this post full circle).