Volgende: Showcase: demonstrating the feasibility Omhoog: Case studies Vorige: An experimental bcoWeb Inhoudsopgave
As discussed in chapter 6, the true value of a well-structured web of domain-specific Ontologies for BC is the support for a new mechanism for information and knowledge sharing. If our computer applications are able to behave as if they understand the language we use to communicate among ourselves and between the various stakeholders, BC processes can be much improved. `Smart' computer applications, including software and hardware (intelligent equipment and robots), that are able to cooperate with us humans like co-workers can provide us with a fast and faultless communication and large-scale re-use of existing information and knowledge.
One of the most important implementations of the new information and knowledge sharing mechanism is the Ontology based Web Service. In the definition of this thesis a Web Service is a recognisable service electronically provided by one or more independent, co-operative computer applications over the Internet. The user sends his data and questions over the Internet to the Web Service and receives (as fast as possible, preferably in real time) the requested answers also over the Internet. The next sections will illustrate the idea.
With the concepts (of the first experiment, see section 8.2.1) stored in the Ontologies, a prototype web application was made that supported the Client in his awareness and decision process. The main focus of the effort was to use only the Ontologies--as much as possible.
The starting point, a one-family house, is fixed. But the application retrieves the available subclasses of `House' and presents them as choices to the user. The selected class is then polled for attributes, which are presented to the user (flat or tilted roof, for instance). The design can be used as the basis for a visualisation following the research of eConstruct [50] where VR shapes were generated as mark-ups from bcXML content files (see figure 8.3).
As a test case some of the applicable rules in the building regulations have been added to the Ontology. As these rules are simply of an if-then-else type OWL has no problem with them. In fact it seems that OWL DL and OWL Full provide a strong basis for this type of applications and opens up a whole new market for knowledge vendors (including R&D institutions). Though time became rather limited we looked into the possibility to check the designs against a knowledge base that contained knowledge to prevent construction errors. From what we did, it seemed that this type of services can be nicely build on-top of the Ontology network. As many other services spring to mind from costs, risks, to a multitude of analyses, the idea took shape that this might become a whole new way to market knowledge and software.
With the instance available, a coupling with the Dutch STABU Specification system has been made. A problem is that the Dutch Specification system does not really support such small projects executed without an architect (it is both an implementation and a legal problem: there are two differing legal frameworks, one for small works like rebuilding and one for bigger works with architects, sub-contractors). The work done is therefore just for test purposes.
An interesting addition to this process was the conversion of the Dutch SfB Classification table (nl-SfB, elementenmethode) to a similar chapter structure as used in the Specification and adding the links from these chapters to the Specification items. Without changing anything in the original data, this second chapter structure could be combined with the resulting Specification items and transformed to HTML as an alternative building Specification.
To be more accurate, the first Specification structure is a work breakdown structure, which is the structure of the Dutch building Specifications. The second Classification (nl-SfB) is normally used (in the Netherlands) for costing applications and CAD drawing layering. As a side note, work is underway at STABU to make the nl-SfB an alternative for the work breakdown Classification in the building Specifications.
Concluding: storing the base data in Ontologies worked well. Both the support application and the Specification generator could use it as a basis for communication. The possibility of subclassing (inheritance) was used well by both applications. The Client support application displayed different kinds of houses (subclasses of `House'), the Specification generator needed a `House' instance as a starting point, but reacted also perfectly to an instance of a subclass. This might not seem like a big deal, but there are not many current applications that have such a thing build-in.
The real support of the Client by warning him for common pitfalls was not undertaken because of time constraints. In this way, only the generation of a simple Specification as a basis for a contract provides a bit of support. On the other hand, the Ontologies contained common solutions for house extensions, preventing possible omissions.
Regarding further work on the instance model, the next stage is obvious: a real interaction with CAD-based data. The only currently realistic option is IFC. When looking at a semantic web supported scenario, it makes sense to use ifcXML. As a baseline, ifcXML files should be downloadable on the Internet, but it makes a lot of sense to expose the normal IFC data store functionality on the Internet. http://example.com/building42/2nd-floor could return an ifcXML file with all elements on the second floor, http://example.com/building42/doors could return all doors in the model. See section 4.2.1 for more details.
Figure 8.5 shows a small case where a catalog and a bcoWeb Ontology are integrated with a project's object tree. An overview of the three files at the basis of the integration is given by figure 8.4.
In the Ontology, the FU `window latch' has a `window handle' as a possible TS. In the catalog, an existing window handle uses the bcoWeb Ontology by connecting to the bcoWeb window handle. In the background, this is modeled as an inheritance relation.
The object tree application, at a certain level in the project, adds a new tree item fed from bcoWeb: a request for a window latch. Normally, the object tree application would only show the bcoWeb-supplied TSs, but when it has loaded the web-readable data from several catalogs, it will also display objects that are subclassed from the valid TSs.
This serves as a good demonstration of the relative ease by which several information sources can be combined when you use semantic web technologies.
