Volgende: Improving market acceptability with Omhoog: Analysis of new applicable Vorige: Using XML and the Inhoudsopgave
The goal of this chapter is to analyse NG Internet technologies for BC. This section analyses the Internet's proposal for a generic vocabulary: OWL. After an introduction, the three OWL variants are analysed. Using OWL by means of references instead of building Semantics into an application is analysed next, followed by OWL's reasoning possibilities. Web services, followed by a summarising discussion, close the section.
XML allows a generic way to deal with syntax; RDF makes it possible to identify and relate data items and also provides a data syntax. This by itself is not enough, what is needed is to make the Semantics of data items explicit. An Ontology can be used to define classes and to provide a list of properties associated with those classes.
OWL is the language used to define Ontologies [82]. OWL is the successor to the DAML+OIL combination of languages. DAML and OIL were the two best and most accepted efforts at an Ontology language to result from the Ontology research community [83]. DAML is of North American descent while OIL is the European development. The two languages had a lot in common, so a combination was agreed upon under the name of DAML+OIL. OWL is a slight clean-up of DAML+OIL and represents the best-practice from the Ontology research community and as such is an important input to BC Ontology efforts.
With RDF and OWL, the web has the potential to become an actual worldwide open database where both structure and content can be directly stored, exchanged and processed by software applications. RDF and OWL are much more powerful than XML. XML data formats have a syntax defined by DTDs or XSD or RNG: these just provide structure. RDF and OWL provide the Semantics, going one necessary step further than plain XML.
RDF and OWL involve a lot of critical mass from multiple industry branches, especially from the (open) software tool support side, both development and CASE tools and infrastructure tools. Powerful free OWL editors are available, like protégé [84], which is a huge difference with for instance the STEP ecosystem in BC, which lacks such generally available tools6.7. Generic availability helps with bringing new instruments to market, see the initial research questions in section 1.3.
An Ontology's goal is to provide a common, referenceable set of concepts for use in communication. It is quite common to use multiple Ontologies, each providing concepts for a particular domain, together forming a rich vocabulary for communication. The term Ontology is discussed more fully in [27].
OWL comes in three variants, each with their own trade-off; they are introduced briefly, in order of rising complexity. All OWL variants build on RDF's schema language. RDF schema allows the specification of (sub)classes and (sub)properties and attachment of properties to one class. Also included are facilities for multilingual names, descriptions and simple values. The OWL variants all add to this RDF schema functionality.
A very useful addition to RDF schema is improved association of properties with classes: properties can now be applied to multiple classes, so that you can use a generic `fire resistance' property on multiple classes without having to resort to one generic supertype for those classes. Lastly, limited cardinality6.8 can be added; the only allowed values are 0 and 1.
Important for good modeling practise are the versioning possibilities like `backwards compatible with', `incompatible with' and `deprecated class/property'.
Description logics is the name of the formalism behind OWL's reasoning/deduction possibilities. OWL DL has one restriction--lifted by OWL Full described below--in order to guarantee deductability of all conclusions that can be calculated from an OWL file [85]. A deduction is for example that if a certain wall is next to a certain door and that door is on the first floor, that the wall is automatically also on the first floor (if the property of `is next to' is defined in that way).
A BC-related example is that of the Ontology class `door'. A catalog item might be an instance of that class, so that you have several doors in that catalog. With OWL DL, you cannot say that an actual door in a project is an instance of such a door from the catalog, as the catalog door needs to be a class for that. In order for catalog items to be instantiatable, with OWL DL the catalog's door should be a subclass of the Ontology's door.
In practice this means that you are forced to stick to subclassing (instead of instantiating) for as long as possible, which does not seem to fit in too well with BC, as there are some distinct levels (Ontology, catalog, much-used items in projects, the actual items).
For BC, OWL Full's lifting of the subclass/instance restriction posed by OWL lite and OWL DL seems to decide the issue in favour of OWL Full. The drawback is that the full reasoning capabilities of OWL cannot be used. In practice, this is only a problem when one completely deduced picture of all of BC (or even of one complete construction project) is desired, an exercise that probably fails much earlier because of the richness and variety of BC objects and viewpoints and the to-be-expected associated incompatibilities regarding Ontologies. Even with OWL Full, powerful restricted reasoning on an object-to-object basis is possible. For the foreseeable future, this restricted reasoning already is a big improvement.
The lack of enumerations in OWL Lite seems to rule it out altogether for BC Ontology usage.
Ontologies all by themselves serve no purpose: they must be used by actual data. By linking information items to Ontology items, the information is enriched and made usable to other applications that support the Ontology.
OWL uses the generic linking mechanism RDF to connect information items to Ontologies. For this, labeled relations can be used. some often-used relations are a build-in, like the `is a type of' relation (instantiation). You can say that item 42 in an IFC file `is a type of' http://ifc.org/definitions/Door.
A useful viewpoint is to treat Ontology Semantics as something that otherwise needs to be hard-wired into your application. Instead treat Ontology Semantics as something that you reference. Semantics are something you can, voluntary, reference from within your data; Semantics are not something you are forced to hard-wire into your data. By referencing Semantics you get a lot of benefits, but it should always be seen as a loose coupling.
It is normally a useful strategy to keep as much data as possible out of applications and to store it as meta-data in external files. This allows the data (including the assumptions behind the data) on the one hand and the application on the other hand to change at their own individual paces. The flexibility given by this loose coupling can be invaluable when data needs to be enhanced: changing the application is much more involved than changing data files, as you need programmers in addition to domain experts.
A case can be made for being formal with regard to the data that is kept externally: [45] formalises this loose coupling as Ontology-driven information system development, keeping the structural data out of the application in the form of a formal Ontology.
Besides being a standardised web format for Ontologies, OWL also allows a certain amount of reasoning. The Semantics of the OWL model elements are well-defined, which is a necessary prerequisite for reasoning. When a certain property (say `door height') is defined as being only allowed on a certain class (say `door leaf'), any object that has that property can be deducted as being part of that class. When needed, this allows you to define class A as being the same as class B, but excluding those objects that have property C.
In practice, you can for instance exclude objects from being a member of the class `load bearing walls' if they are not connected to another supporting load bearing structural element, like a foundation. This way you can detect possible failures on the condition, of course, that the Ontologies and supporting applications are detailed enough.
[86] advocates an integrated approach by saying that ICT (Internet) should be an integral part of company and project knowledge management systems .
The semantic web is a term often used for the collection of technologies analysed here, taking the normal web one step further. On the web, you can access lots of documents with a URL and link from document to another document anywhere; on the semantic web, you can point from one object to another object anywhere in some file: the semantic web extends the URL mechanism to a GUID mechanism [8]. Build into the semantic web is the idea of Ontologies, providing also a special format for Ontologies: OWL.
A combination of web services and semantic web makes the web services' advantages bigger, as it makes the data that goes over the wire even more web-centric. For BC, this merges two technologies that both enable a better and more dynamic information exchange: generalised, reasonably simple data structuring plus simple and ubiquitous data exchange. The combination makes it even more attractive for BC.
Comparing the functionality of OWL with other languages like 12006-3 or eConstruct's bcXML Taxonomy format shows that OWL is really a generic, small, but very flexible core model. The W3C people wanted to be able to formally define OWL in a very precise way and therefore left out meta-concepts that were hard to define as a language construct. The industry-independent approach ensures future possible interoperability and re-use in and between different industry sectors.
An interesting feature of OWL is that missing functionality of basic OWL can be added by using OWL itself to describe the extensions. A recent effort of TNO in the Netherlands resulted in a number of extension Ontologies containing, for example, the 12006-3 based archetypes like `activities' and `actors'. Other examples of what they added in a test setting are units and complex properties, IFC-like placement and composition.
A strong point of OWL is that its Semantics are formally defined, using DL. This puts it ahead of BC initiatives like IFC and 12006-3, which do not have the formal logic behind them. 12006-2, more or less a formalisation of the SfB system, has formal logic that defines the core concepts, as, in their opinion, in order to achieve clarity in communication and technical development, a common conceptual framework is needed [87]. This can perhaps be extended from the Ontology's content to the Ontology technology itself.
Attesting to RDF's and OWL's thought-out model is that some of the concepts explicitly modelled in 12006-3 and bcXML are treated in a much more comprehensive way. URLs are used for unique identification, which provides both an elegant GUID and a mechanism for extension, because other Ontologies can expand upon the concepts defined by those URLs without a need for those expansions to be included in the original file. Also multilingual labels and descriptions are build into RDF using a standardised XML method.