|buildingSMART alliance Database Exchange Forum Project|
Database Exchange Forum
Within This Page
ORGANIZATION: buildingSMARTalliance (bSa), Department of Veterans Affairs (VA), Construction Specifications Institute (CSI)
As standardized "information exchanges" are now being implemented ( e.g. COBie being first out of the blocks), there needs to be an approach to provide consistent naming object attributes, especially for organizations with large portfolios of facilities. Currently, the ability to efficiently flow data from BIM authoring tools, which provide unrestricted flexibility with attribute names, into more data structure dependent downstream applications is essentially non-existent. It is this inability to efficiently move data across applications that is uncovering interoperability gaps in the information exchanges formats. It has been asked "Is there a way to "standardize" data attributes (properties) to create a more interoperable data flow?"
The US Department of Veterans Affairs (VA) has been looking into this attribute naming issue for their BIM – Facilities Management (FM) handover implementation but felt it was a bigger problem than just theirs and wanted to put their concerns in front of several AECO industry database experts. What began as an assembly of seven software vendors ( Bentley / AutoDesk / Graphisoft / TMA / IBM / Assetworks / ESRI) plus five Federal Agencies (VA/GSA/FAA/DOD/NASA) with their database consultants (AEC Infosystems, CFI, Cannon Design) has now grown into a much larger group of stakeholders including Office of State Department, State of Wisconsin, Onuma Systems, EcoDomus, Beck Technology, FM Systems, and Vectorworks, as well MA Mortenson, DPR, MC Dean, and even International participation ( Norway, Finland).
For a single building or project, attribute naming conventions has not been seen as an issue, but when consolidating multiple building data, the use of inconsistent attribute names appears to create unforeseen problems. This project intends to first verify that this problem indeed does exists, then determine if inconsistent attribute names need be solved by the individual user or vendor, or is it more systemic and required an industry solution. To answer to this question, it must be posed to a group of vendor and end users database experts. If it's found to be an industry problem needing an industry developed solution, then the group will reach out to other stakeholders to corroborate their findings. With more industry involvement, solutions can be explored; a proof of concept developed and demonstrated; and, finally a pilot project used to validate the solution properly addressed the problem.
March 27, 2012 Meeting
The main purpose of the first meeting on March 27, 2012 was to determine if inconsistent attribute names was just single user issue or a systemic industry-wide issue? It was determined by all the attendees to be an industry issue needing to be solved. The solution the VA proposed was based on the creation of a web-based centralized repository to store and maintain the common attributes, and could be accessed by all users. At the close of the meeting, next steps were established, first being to identify and select an existing effort which would provide centralized database solution, then explore that as a solution, and reconvene with a demonstration. One current project considered was the buildingSMART Data Dictionary (bsDD) as it had an established database of common terms.
June 19, 2012 Meeting
With bsDD technical assistance from Havard Bell/ Catenda working with Malcolm Junkin, VA consultant, a proof of concept was developed to show the centralized database approach proposed by VA. The next meeting, held on June 19, 2012, was with the extended group to observe a proof of concept demonstration using select lists of attributes created by a user, and then pulled into a common repository, which then was accessed by a vendor for inclusion in their software application. To demonstrate the change management in the process, the initial attribute list was then modified and updated in the repository as well as by the vendor for their software update. Although the demonstration did show conceptually how the centralized database approach could be a solution, there were still details needing to be addressed that are not available within the current bsDD configuration. The group mutually decided a creation of a true pilot project would be the next step. Several attendees agreed to provide in-kind support and others offered current projects as possible pilot opportunities. A written pilot proposal is to be provided back to the group for review and discussion.