5.3 Topological structure

EXAMPLE

For instance, the class StorageArea would contain all the individuals that are storage areas in our domain of interest which might be ElectricalMaterial_StorageArea or InstrumentationMaterial_StorageArea. Classes are organized into a superclass-subclass hierarchy. Subclasses specialize (‘are subsumed by’) their superclasses. Another example could regard the classes MicroLevelSpace and LaborCrewSpace. A Labor Crew Space is defined as subclass of MicroLevelSpace, meaning that ‘All labor crew spaces are micro-level spaces’ and ‘All individuals (user-setted) of the class LaborCrewSpace, for every given construction method, will be automatically members of the class MicroLevelSpace’.

5.3 Topological structure

Here, the framework models of the ‘space ontology’ is depicted in terms of classes, properties and relations, by mean of the same text notation introduced in the previous Figure 5.2. As before mentioned, core class of the space ontology is ConstructionMethod. It is the first user interface regarding the ontology compilation and comprise all those data that shall be provided for the workspace planning in the prosed system architecture. It means that the user adds individuals to all those classes, described below, the ontology is made of. Each construction method isDefinedBy a WorkDescription. A WorkDescription defines a Demand in terms of Procedure and SafetyRule. A Demand requires some Resources. Different classes of Resources are defined according to the Scheduling Ontology but regarding the matter in question, care should be taken on the class SpatialResource. A Spatial Resource shall occupy a Micro-Level-Workspace. To manage this relation a cardinality restriction1, which specifies the exact number of relationships that an individual must participate in, is added (Figure 5.4). Instead a Minimum Cardinality Restriction is used to ensure that the user will link at least a resource to each construction method.

1 In OWL language, we can describe the class of individuals that have at least, at most or exactly a specified number of relationships with other individuals or datatype values. The restrictions that describe these classes are known as Cardinality Restrictions. For a given property P, a Minimum Cardinality Restriction specifies the minimum number of P relationships that an individual must participate in. A Maximum Cardinality Restriction specifies the maximum number of P relationships that an individual can participate in. A Cardinality Restriction specifies the exact number of P relationships that an individual must participate in.

•

5.3 OWL restrictions to specify the number of spatial entities assignment required to operate

EXAMPLE

By using the aforementioned restrictions if the user, for example, adds an individual ColumnInstallation_LaborCrew that is a member of the class LaborCrew-Space and in parallel he doesn’t add a Spatial-Resource the Consistency Reasoner will suggest an inconsistency. Otherwise, if the user adds an individual of the class Procedure which could be, for example, ColumnInstallation_Procedure, without linking a Resource, the reasoner suggests again the inconsistency due to the Minimum Cardinality Restriction (min 1) which drives the relationship between classes of Procedures and Resources. In this way, the ontology ensures that on one hand the given resource is graphically simulated and that on the other hand the resource is computed by using the Knowledge base included within the Scheduling Ontology.

Going on in the description, a Resource might handle one or more Activities which, in turn, require at least one Micro Level Workspace. Adding a number of individuals, the user may choose how many Workspaces handle an activity, with their attached properties. In such ontology framework, restrictions are used to specify that a Procedure requires at least one Resource, and that a SpatialResource occupies exactly one WorkSpace and so forth as shown in the figure above.

Different types of workspaces are included in the model by using superclass-subclass relationships. Hence, the class WorkSpace contains three subclasses: Macro-WorkSpaces, Micro-WorkSpaces and Bound-Spaces which represents physical entities in terms of site boundaries and objects that reside on site before the commencement of activities. Five subclasses support a more explicit description of ‘Micro Level’ space subtypes:

•

5.4 Workspaces entities organized in the space ontology in a class hierarchy

LaborCrew-Space represents the space required by a labor crew during the execution of a Construction Method. Protected-Spaces are required to protect the construction product for a given time interval. Equipment-Spaces identified spaces occupied by the equipment during the execution. In many cases both labor and equipment might generate a Hazard-Space which is considered different from a Safety-Space that represents a safety distance between two workspaces to prevent safety hazards such as collision between two spaces or a tolerance space from objects falling from height or moving in site. The complete class hierarchy consist of the classes given in the following figure. Although the construction of the abovementioned class hierarchy may have seemed rather intuitive so far, in OWL subclass means necessary implication2 . Each class of Workspaces contains four groups of Datatype Properties which support their geometrical and non-geometrical representations. Datatype properties link an individual (which in this case means a workspace entity user-entered, e.g. ScaffoldingSpace) to a Datatype value. In other words, they describe relationships between an individual and data values. The proposed classification is set out in Figure 5.5.

2 The fundamental taxonomic constructor for classes is rdfs:subClassOf. It relates a more specific class to a more general class. If X is a subclass of Y, then every individual of X is also an individual of Y. The rdfs:subClassOf relation is transitive which means, if X is a subclass of Y and Y a subclass of Z then X is a subclass of Z.

•

5.5 Diagram of the property set for representing a workspace within the Space Ontology

•

5.6 Graph visualization representing classes and relations in the Space Ontology (Snippet from the Ontology Modeling Environment Protégé)