Facilitating distributed collaboration in the AEC/FM sector using Semantic Web Technologies

Classes In traditional software engineering, the notion of an 'abstract class' is used to model supporting structures that gather some attributes or functions that all children classes have in common but which itself cannot be instantiated. This however has no equivalent in DL and hence is not a language feature of OWL: For a simple hierarchy like C1 v C2 u C3 C2 v C4 u C5 C3 v C6 u C7 u C8 the concept or class C1 may only be called abstract if no individual In exists that is a member of the classes C2,C3 . . .C8, since C1 subsumes all these, and hence is instantiated if any of the subsumees is instantiated. For the purpose of generating software classes from the OWL model in a classic OOP or MDA environment, the indication that a class should never be instantiated directly (e.g. the IfcRoot class at the top of a big fraction of entity de nitions in the IFC model), can only be achieved indirectly: ˆ A semantically weak way would be to make an additional annotation to the class in question. ˆ Amore semantically rigid way is to subclass a meta class from owl:Class that has additional attributes like "abstract" and concrete . This however would instantly make the ontology OWL Full and hence That is: not every owl:Class in the resulting ifcOWL ontology stems from a an ENTITY counterpart.