I have just been going through some old articles I have lying around and came across this:

The 7 (f)laws of the Semantic Web

Within the article Dan Zambonini lists seven issues he sees needed to be addressed by Semantic Web proponents in order to improve its chances of adoption.

1. Not all Semantic Web data are created equal.
2. A technology is only as good as developers think it is.
3. Complex Systems must be built from successively simpler systems.
4. A new solution should stop an obvious pain.
5. People aren’t perfect.
6. You don’t need an Ontology of Everything. But it would help.
7. Philanthropy isn’t commercially viable.

Personally I think these are all excellent points which if overcome would considerably improve the adoption chances of many Semantic Web related technologies.

The Semantic Web is an ideal that has been around for a long time but has never reached critical mass. Recently a number of American journalists announced the ideals of the Semantic Web were alive and kicking in the guise of Web 3.0. Personally I think this is a fairly naive thing to say for a couple of reasons.

Firstly Tim Berners-Lee's concept of the Semantic Web existed well before the term 'Web 2.0' was even a glimmer in Tim O'Reilly's eye. So to launch a rebranding exercise and announce it as the new big thing ignores the fact it actually lost out to the simple, socially motivated read/write concepts which are the embodiment of 'Web 2.0'. Whatever evolves from the hype that is 'Web 2.0' will certainly not be the Semantic Web as previously envisioned. Instead it will inherit many of the aspects which has come before it whilst simultaneously adding a new twist, perhaps Semantic Web related (or not), which gets Web users and investors excited.

Secondly launching a crusade for the next big thing well before the benefits and lessons of 'Web 2.0' have been disseminated will ensure this next version of the Semantic Web meets the same fate of its previous incarnation. At issue is the fact that the Semantic Web concept represents a number of digital information and relationship ideals. Striving to meet these ideals should be the long term ambition of all future iterations of Web technologies, including 'Web 3.0' if it ever materialises. Attempting to simply package up these ideals into a set of technologies which get forced on an unsuspecting, and to a certain degree unwilling user base will only result in one thing: rejection.

I have had a fairly positive response to my last CAD Collaboration post. Feedback has highlighted a couple of areas that need clarifying and developing a little further.

On Snapshots and Deltas

Paul Wilkinson of the Extranet Evolution blog put up a fairly long post that discussed many aspects of the article. Of most interest was his comments on the snapshots and deltas idea, significantly the fact that a similar approach had been adopted three years ago by BIW Information Channel from BIW Technologies.

BIW’s Accelerated Transfer pack condenses file revisions to a fraction of their previous size allowing faster transfer – up to ten times faster in the case of some files.

In the case of BIW it used delta encoding as a means of increasing data transfer speeds to remote, poorly connected places such as construction sites. This is slightly different to the concept I proposed because it deals with binary deltas rather than deltas at an abstracted digital model level. Binary deltas are great at a file level because they do allow changes to the same file be transferred somewhere very quickly. The problem is that binary deltas are intended to convert a file to a carbon copy of the remote source file from top to bottom.

Using delta's in a collaborative digital model is all about exchanging design intentions (i.e. rotated wall A 45 degrees) so that the model is updated but many properties of the actual file remain the same. In many respects it is more complex process than a low-level delta courtesy of a tool like diff. However this added complexity provides the benefit of enabling users to choose what design intentions they wish to inherit from other team members without worrying about the associated digital baggage that accompanies their team member's file.

(or how I learned to stop worrying and love ambiguity)

This post covers the issues surrounding CAD collaboration and past approaches to resolving it. It then concludes with a concept of how decentralised digital model development could be undertaken in a manner that reflects the ambiguous environment in which collaborative design is experienced.

The Problem of Digital Model Orientated Collaboration

Modelling an architectural design in CAD almost never occurs in an isolated environment. Typically work is undertaken with at least one other person simultaneously in order to meet development deadlines. Unfortunately issues arise when participants wish to simultaneously change the same design element, or a set of design changes inadvertently effect another aspect of the digital model.

Recently I was asked to comment on a debate that was raging in the Vectorworks forums related to its minimal set of collaboration functionality. Whilst the forum thread initially begun as a feature request it soon evolved into rather heated debate over how collaboration functionality in CAD should function (if at all). Central to this online debate was the role internal offices processes and politics held in the success of a collaborative digital model. Whilst this is typically the most visible factor we must also keep in mind the mere introduction of digital models has significantly altered our collaboration psyche.

Yahoo Pipes is aiming to be to Web mash-ups what Microsoft Access was to relational databases. Prior to Access, relational databases were primarily the domain of the highly trained database administrator and software programmer. Microsoft Access significantly changed the game by providing a relatively powerful database experience in a manner that the mainstream audience could comprehend and be productive with. As a consequence the business world is now saturated with mission critical Access databases put together internally by the employees themselves to meet a set of data challenges unique to that particular company or department. With Pipes, Yahoo is attempting to become the Microsoft Access of the Web 2.0 market space.

Well it may not be 42 but this great video by Michael Wesch an Assistant Professor at Kansas State University does an excellent job of visually explaining what Web 2.0 is all about and how it differs from conventional media and the Web we all go used to prior to this Century:

Web 2.0 ... The Machine is Us/ing Us

Recently Autodesk dropped the price tag off their Autodesk Design Review package making it far more accessible to the Architecture, Engineering and Construction (AEC) industry. Design Review is a DWF-centric tool for viewing and reviewing 2D and 3D design documentation. Prior to becoming freely available Design Review appeared to the casual observer as a useful tool for those heavily into Autodesk products but not the mainstream audience. This pricing shift changes the game and enables the software to compete against Adobe Acrobat as the primary, general purpose viewing tool for design documentation. With this in mind I took a fresh look at the software and what follows is what I found.

The term Building Information Model (BIM) is used fairly loosely in the Architecture, Engineering and Construction (AEC) technology industry. Most of the software 'formerly known as CAD' is now referred to as a Building Information Modeller (i.e. Autodesk Revit), or at a minimum reference the term in their marketing blurb. In the field of AEC research many papers reference the Building Information Model as a hypothetical construct holding boundless quantities of data about a building. This approach avoids a commitment to a particular technology (which in research is not a bad thing) but it does mean the definition of what is and is not a BIM becomes even less clear. Perhaps the best general description of what a Building Information Model is without resorting to either “whatever program X supports” or “pretty much anything” is from Jerry Laiserin when he first proposed that the industry stop using a range of terms and focus on just one.

“Combined, "building information" implies, to my ear, a strong sense of what the design, construction and operation of buildings is about. It avoids techno-jargon, yet remains evocative of technical goings-on. "Modeling," although a near-jargon word, does connote the mathematical or digital description of objects or systems, we have econometric models and weather models as well as physical models of 3D objects. "Modeling" also implies a process of description or representation that provides the foundation for building performance simulation (essentially, modeling future behavior) and for the management of building information (information models serving as the frameworks in which information is managed).” - Jerry Laiserin

On the 29th January Adobe announced it will be seeking ISO certification for the PDF 1.7 standard. Up until this point many vendors have been able to implement the PDF standard based solely on trust that Adobe will not significantly change the format and break their respective implementations. If PDF gains ISO certification then this will ensure any vendor can develop for and use the standard in the knowledge that it will not change and be 100% interoperable with other implementations of the same standard.

This is good news for governments and business as it means once certified PDF will become a permanent, unencumbered format. These characteristics will enable organisations to use PDF as an archiving medium for 2-dimensional digital documents with the confidence that no single company can dictate or control the use of the format. This is important because in the past companies like Microsoft have unduly effected the industry with their monopolistic control over formats (as evidenced by the infamous Halloween Memo).

Last week I was invited to attend a meeting of a few local architects where they discussed the Building Information Model and its relationship to documentation. Before attending I prepared the following document which I distributed amoungst the attendents. In it I aimed to clarify what BIM is (or more importantly what is isn't) and give them an indication of the issues surrounding the concept of BIM from a macro-perspective. Most attendants were very familar with the power of BIM tools such as Autodesk Revit but in general there was a lot of confusion between BIM and parametric modeling. There were also mixed feelings on the capabilities of BIM as a collaboration platform. For the practices involved it had helped internal processes but it was acknowledged that getting disparate information from design team participants into a BIM was a challenging task. Interoperability between various BIM platforms was an issue but there was the greater factor that many people working within the industry still produce relatively 'dumb' (i.e. basic 2D/3D drawings) that need to be practically recreated in BIM if it is to be of use within the model.

What follows is a web version of the printed document I distributed for reference:

Behind the Building Information Model Buzz

The 'Building Information Model' (BIM) is a marketing buzzword that has been heavily promoted by many Architecture, Engineering and Construction (AEC) software vendors. But what exactly is it, how will it effect the way you work and will it solve all of your problems?