With the current trend of using Linked Data to describe buildings during their entire lifecycles, the importance of product descriptions in a Semantic Web context is growing while most product ontologies are designed for mass-produced goods of little variance. But especially in the construction industry, products are often innovative and individually manufactured and previous attempts to depict them with ontologies failed to include meaningful alignments to already existing approaches. Thus, this paper gives an overview of existing product ontologies in general and analyses previous approaches in more detail to identify potential improvements that can be made. Based on this analysis, this paper presents the Building Product Ontology (BPO), including its concepts and alignments. To obtain a modular ontology, the BPO focuses on the non-geometric description without defining templates by determination of taxonomies and includes concepts to model assembly structures, interconnections of components, and complex properties and property values. The BPO enables manufacturers to freely model their products while still benefitting from the Semantic Web in respects of findability and availability of product data. By going through the given examples and demonstrations, inexperienced users are supported to apply the BPO and exploit its benefits.
The progression of digitisation in the architecture, engineering and construction domain (AEC) is premised on various approaches and different technologies. Recently, approaches using Semantic Web technologies and Linked Data have produced interesting results for digital building models, sensor data, collaboration, and other fields of interest. However, for the industry to recognise their potential, all aspects of the building lifecycle must be addressed by these approaches, including product descriptions.
Currently, several approaches to describe products in a Semantic Web context exist,
but most of them were developed from other perspectives and domains and thus are
not suitable for building products. To create means for describing innovative and
multifunctional building products, the SolConPro ontology was introduced in [
Nonetheless, the SolConPro ontology still exists as an island solution, since it is neither aligned nor linked to other { more prevalent { ontologies and approaches. It also does not follow basic principles of web data like re-using and adapting existing approaches and ontologies instead of defining already known concepts anew.
To increase the benefit users may have by using this ontology, we are presenting a revision of the former SolConPro ontology in this paper. The revision includes alignments to other ontologies, modularisation of the former SolConPro ontology, re-usage of concepts from other ontologies, and refinement of the defined concepts.
Next, we will discuss approaches for product-related ontologies, including a more detailed analysis of the SolConPro ontology, including an analysis on its shortcomings. Based on this discussion and analysis, we will present the new Building Product Ontology (BPO), which is build upon the SolConPro ontology. Following, a proof of concept of the BPO ontology is shown. Finally, we conclude this paper and give an outlook on future work. 2
Within this section, we differentiate between three types of related ontologies: Common product ontologies, which are widely used, but focus on offering either very generic product descriptions or descriptions for store-based products in e-Marketplaces; product ontologies from different domains, i.e. from mechanical engineering, food industries, etc.; domain ontologies from the architecture, engineering and construction sector.
Each of these categories must be regarded within the ontology revision. However, the impact those categories should have on it vary. For example, an alignment towards common product ontologies is of high importance for manufacturers, so their products will be easier to find and be interpreted by search engines and thereby also by their potential customers. But at the same time, these ontologies may not be suitable to describe the product's structure or interconnections. On the other hand, product ontologies from different domains may already introduce concepts to describe assembled products or product interconnections, while their benefit from the perspective of search engines might not be as crucial. Meanwhile, domain ontologies are of high importance for the end-users of the product descriptions, as they want to easily include the products into their digital building models and the building lifecycle.
All considered ontologies of this paper are summarised in Tab. 1, together with their prefixes and domains. 2.1
The most popular common product ontology is the GoodRelations ontology. It was
originally designed for online services of the non-parametric retail market with mass
produced products [
The GoodRelations ontology is widely included into the schema.org ontology that aims to serve as a central vocabulary to help provide structured data on the web in a unified way. It was founded by Google, Microsoft, Yahoo and Yandex and is supported by web applications of different domains. The ontology consists of several parts, one of which is dedicated to describing products and services. Though the product part of schema.org is based on the GoodRelations ontology, both approaches differ in detail and abstraction levels at some points as well as their namespaces, with schema.org allowing more flexibility for describing not just products but also parts of products.
Another common ontology with wide range is the Suggested Upper Merged Ontology (SUMO)4, which is merging domain ontologies from various fields. It is { in contrast to the other mentioned ontologies { written in the KIF language, but a translation into OWL is also available. Within SUMO, various concepts from a wide array of domains are collected, including more generic concepts like such for (manufactured) products and generic property or attribute properties. Nonetheless, since this ontology is not built in modular manner and its based on KIF with OWL just being a translation, its application for a flexible and modular product ontology in RDF seems not viable. 2.2
The topic of product description ontology has been discussed for many domains, e.g. manufacturing, mechanical engineering, and the food industry. The underlying approaches differ in multiple aspects, but the most distinct observed differentiation is
the modelling of product (de)composition in form of geometric assemblies, e.g. with
Open Assembly Models (OAM, [
In 2010, [
More recently, the Feature-based Product Ontology (FPRO) which is based on the
Lightweight Upper Level Ontology (LUPO) were designed [
The discussed ontologies are not aligned towards other ontologies, i.e. schema.org and GoodRelations, and contain additional concepts as process management, geometryand time-based constraints for the assembly process, and material descriptions. 2.3
Within the AEC domain, efforts have been made to describe buildings and products within a web context and should be considered during the design of the BPO.
Regarding product descriptions, definitions of terms for components and properties or property sets from the widely used Industry Foundation Classes (IFC) were translated to RDF (PRODUCT 5, PROPS 6). The PRODUCT ontology additionally provides means to describe simple aggregations between products. However, it restrains these connections to products alone, therefore every part of a product must be a product itself, which does not hold true in all cases.
Meanwhile, the PROPS ontology can be created automatically based on the IFC
standard. It also defines the property domains and ranges, where concepts of the
Building Topology Ontology (BOT) are reused. BOT serves as a reference ontology
that describes a building's topology [
PROPS is not aligned towards common vocabularies and does not allow to add
further information or meta data to the properties. In order to overcome the lack of
connection to meta data, the Ontology for Property Management (OPM) was
introduced. As shown in [
Before we present the new BPO, we will briefly summarise the SolConPro ontology
[
The SolConPro ontology itself introduces concepts for assembly relations, including the usage of so called entity nodes for typification of objects with individual values. Since a relevant part of a BIPV module's description are its electrical interconnections, the SolConPro ontology also contains classes and properties to describe generic interconnections between placed entities. Apart of the product structure, the ontology can also describe properties of varying complexity. The considered properties span from simple, one-value properties to ones with value ranges, step sizes or intervals; the most complex properties are based on unstructured, two-dimensional lists that relate the values of two different properties. 3.1
Missing Modularity. The SolConPro ontology, though still small in comparison to e.g. the ifcOWL, addresses multiple, non-related topics, i.e. general product description and parametric dependencies. Thus, re-using one specific part would require to also import the non-related functionalities and thereby cause unnecessary overhead. Instead, non-related topics should be separated and imported only where needed.
Also, the proposed methods to link the SolConPro ontology to other ontologies are not ideal in respect of modularity. By only linking to IDs instead of individuals, information is harder to evaluate. And creating direct mapping structures on Tbox level may be more effective for the considered ontology combination, however, the mapping must be adapted or re-designed for other combinations. This is not just cumbersome but can also impede unified querying.
Undesired Impacts of Inheritance. Inheritance relations may have undesired effects on the data, if not considered carefully. Within the SolConPro ontology, two of those cases appear. First, the scp:Product class inherits from the scp:Assembly class, which represents components that are assembled by other components. Yet, this relation { in combination of the disjointness of the scp:Assembly and scp:Element classes { causes a restriction upon products that they have to be assembled by components, which may not hold true.
Second, the SolConPro ontology differentiates between properties with exactly one value (scp:Attribute) and those with value ranges or multiple values. However, the latter (scp:DynamicAttribute) inherits from the other, which leads to inconsistencies: scp:Attribute individuals should have exactly one value, while scp:DynamicAttribute individuals may have up to one value, but inherit the restriction from scp:Attribute. This inconsistency was not detected by reasoners, since it does not cause logical contradictions.
Missing Expressivity. One can argue whether it is beneficial to apply highly expressive ontologies, since they create a valuable benefit for generating information on the one hand, but cause performance issues and may quickly become so complex that they are barely manageable on the other hand. The SolConPro ontology has an expressivity of SRIQ and can therefore be considered more expressive. Nonetheless, it is not using this level of expressivity to a full extent: Most sibling classes are not defined to be disjoint, restrictions are not defined as class axioms consistently and it contains one defective chain axiom for entity connections. The latter is supposed to create a chain for two entities that share the same scp:ComponentConnection. Yet, one of the relations is misdirected.
Ambiguity. Another shortcoming of the SolConPro Ontology are the chosen vocabulary names and a missing documentation. If an ontology is expected to be re-used by other parties, it must contain a detailed description of its concepts and, ideally, a public step-by-step instruction on how to use them.
Missing Alignment. One of the main arguments for describing products using Semantic Web technologies is the advantage during customer-searches created by the search engines. As discussed in Sec. 2.1, some ontologies like schema.org and GoodRelations are supported by common search engines. To gain this advantage, product ontologies must be aligned to those ontologies.
The advantages from search engines are not the only reason for aligning ontologies.
[
However, the SolConPro ontology is not aligned to other ontologies. Thus, most benefits from using Semantic Web technologies for product descriptions are voided. 3.2
The SolConPro Ontology was designed based on the needs to describe highly innovative and multi-functional building products. It introduces concepts that allow users to describe their products without restrictions by templates, while still being able to define products in high detail. Nonetheless, the ontology is unlikely to create a noticeable impact on the industry, since it is not exploiting its full potential. Therefore, a revision of the ontology with the aim to solve the identified shortcomings may increase the effectiveness and thereby also applicability by the industry. 4
Based on related approaches for describing building products in a Semantic Web context and the discussed shortcomings of the SolConPro ontology, we designed the Building Product Ontology (BPO) presented in this section.
With the overall concept of a multi-layered product ontology, the BPO is meant to
serve to describe a product structures and properties only. Thus, the connections to the
other layers { both in general and via parametric dependencies { are not a central topic
for the BPO. Besides, the field of application of the SolConPro ontology is transferred
to the BPO: highly innovative, multi-functional building products on the example of
facade components. Subsequently, requirements for the SolConPro ontology { except
for parametric dependencies { hold true for the BPO: it should follow a flexible,
nontemplate-driven approach allowing multi-classification and can easily be extended [
As concepts and terms from the SolConPro ontology are the basis for the BPO, Tab. 2 compares the statistics of both ontologies. The BPO does not introduce concepts or properties for new topics, but enriches the existing terms, while at the same time reducing the overall expressivity in favour of performance and handling. It is visible that, though less classes and properties are part of the BPO, it still contains more triples than the SolConPro ontology. This highlights the advancements made in respect of exploiting the used expressivity. Concepts of the SolConPro ontology the BPO is not re-using, are either dropped because the scope of the ontology was reduced or replaced by suitable concepts of other already existing and popular ontologies (e.g. schema.org).
Next, we will discuss examples of the changes between the SolConPro ontology and the BPO. These changes can be grouped into the categories Modularity, Inheritance, and Expressivity. After the adaption on schema-level is shown, we will continue to present its alignment to relevant ontologies presented in Sec. 2. 4.1
Apart of more tangible changes, the naming was re-evaluated, unified in its convention, and adapted to be more unambiguous, where needed. The aimed non-ambiguity of the ontology is also the reason for renaming it, since the name Building Product Ontology is defining the ontology's scope more clearly than the name SolConPro Ontology. Additionally, the BPO { with its online documentation { are published online. Modularity. The scope of the BPO is reduced to describing the product structure itself. This includes defining assembled components with optional entity nodes, entity interconnections, component and product properties, and complex attributes. Subsequently, all concepts except those for parametric dependencies are re-used.
Moreover, connecting geometry descriptions is no longer realised by mapping classes. Instead, we recommend to use the Ontology for Managing Geometry (OMG) resp. File Ontology for Geometry formats (FOG) to create flexible and uniform links. Since the authors are unaware of a vocabulary for building products and properties in a Semantic Web context, the bSDD is still used within the BPO and connected via datatype properties that have the classification superclass as domain. Inheritance. The discussed problems with undesired impacts of inheritance have been resolved by adapting the class hierarchy (see Fig. 1): For instance, bpo:Product is now a direct subclass of bpo:Component, while it is the only class that is not disjoint with all sibling classes. Thus, users can define any Assembly or Element to also be a product. Furthermore, the bpo:Attribute and bpo:RangedAttribute are modelled as sibling classes, removing the inconsistency regarding value cardinalities. Expressivity. As is shown in Fig. 1, the BPO defines disjointness (red boxes) between all sibling classes with the exception of the bpo:Product class. Besides disjointness, additional class and chain axioms are part of the BPO:nine class axioms and four chain axioms. In comparison, the SolConPro ontology includes seven class axioms and four chain axioms for the concepts that were taken on to the BPO. All axioms from the SolConPro ontology were re-used, wherefore one class axiom was supplemented and two others were aligned towards other ontologies while the faulty chain axiom was rectified.
The rectified chain axiom belongs to the bpo:isConnectedTo property (see Fig. 2) and is defined as (1). To fix the error, the former scp:hasIncomingConnection property is inverted and renamed as bpo:connectsInputOf. Apart of the rectified chain axiom, the symmetric bpo:isConnectedWith property between two bpo:Entity individuals is introduced to for non-directed connections. bpo : hasOutgoingConnection bpo : connectsInputOf (1)
The supplemented class axiom belongs to the renamed bpo:RangedAttribute class (based on scp:DynamicAttribute) and was adapted to restrict every instance of it to have at most one specific, minimum and maximum value as well as one unit and permitted step size. Previously, the scp:DynamicAttribute was restricted to have exactly one specific, minimum and maximum value and at most one unit and step size.
Furthermore, two new class axioms are introduced, both concerning components. The first defines bpo:Assembly to consists of at least one component and at one of the connected components has to be of the type bpo:Element. Meanwhile, the second axiom determines bpo:Element not to use the bpo:consistsOf property.
These axioms were added to emphasise and specify the assembly descriptions of BPO (see Fig. 3): Assemblies can consist of at least one other component, while elements cannot { or will not { be further disaggregated. Since the BPO is disconnected from geometry and material definitions, it is possible for manufacturers to describe components as elements, even though they are not made from one material or part. This can be used to keep more detailed product information that might contain corporate secrets like used materials or techniques from being spread.
However, by allowing the definition of bpo:DynamicEntity nodes without requiring a geometry description as well, information as the quantity of placed entities get lost. Therefore, we introduced the new datatype property bpo:hasQuantity with the domain of bpo:DynamicEntity and range of an xsd:integer.
The adaption of the ontology does not only concern its structure, but also its alignment towards other ontologies. Figures 1 and 3 already give insight about re-used classes. The complete alignment will be presented in this section and is separated into three categories: Assembly structure, property and product.
Assembly Structure. The description of assembled components is discussed by several ontologies, the most relevant for the BPO are schema.org, GoodRelations, LUPO, and FPRO. Schema and GoodRelations mainly focus on properties between products to define spare parts or consumables. Both relation types are not suitable for the BPO and would also impose the restriction that every component would be a product.
The more product { and assembly { focused LUPO and FPRO, on the other hand, introduce a differentiation between part-whole and assembly relations of components (lupo:hasPropertPart and its subproperty fpro:hasComponent). This allows to give a more detailed, part-based description even for components that are not technically assembled (e.g. screws). However, at the same time, these ontologies restrict components and products to either be physical or not and thereby enforce geometry and material descriptions on every part of a product. Another restriction on assembled structures is that they must consist of at least two products of single materials. Again, this implies every component to be a product. Thus, from the perspective of assembly structures, no alignment is proposed.
Property. Multiple alignment options for property descriptions exist: From generic ontologies as schema.org or GoodRelations, other product ontologies and already implemented approaches of the building domain, i.e. OPM and SEAS. A challenge in finding optimal alignments is the requirement for the BPO to still enable flexible modelling.
Within GoodRelations, property values are not linked directly to objects, but defined with an intermediate node between products and its property values. Also, a separation between quantitative and qualitative properties is defined both on class and property level. Quantitative ones may use properties to define minimal, maximal, and singular values, as well as units. On the other hand, qualitative values consist of descriptions and relations (e.g. lesser, equal, etc.) between each other. The vocabulary also predefines common product properties as width, height, etc. Nonetheless, the separation of qualitative and quantitative properties complicates unified querying if the product architecture is not known beforehand, and since all properties are defined to belong to products, this would imply every component with a property would be a product.
Since schema.org re-uses most concepts of the GoodRelations vocabulary, the concepts presented above are part of schema.org as well. Furthermore, schema.org introduces concepts to add schema:PropertyValue nodes to places, products, and other properties for the description of neutral (either qualitative of quantitative) properties via the schema:additionalProperty property. It can additionally be enriched by a property identifier, which could be used to add the bSDD ID of the property. Both schema.org and GoodRelations are using unit codes to define the used units instead of linking to ontology-based vocabularies of units (e.g. the QUDT).
In the building domain, the OPM was proposed to describe properties on
different levels of detail. The approach for property modelling that was chosen in the
BPO compares to the Level 2 of [
The overall alignment of the BPO attributes can be seen in Fig. 4. From the aspect of attributes, both bpo:Attribute and bpo:RangedAttribute are subclasses of schema:PropertyValue and seas:Property. The bpo:hasAttribute property is a subproperty of schema:additionalProperty and seas:hasProperty. Instead of using units that are defined within the BPO, units should be linked from the QUDT using qudt:Unit individuals and qudt:unit properties. Values can be described using schema:minValue, schema:maxValue, and schema:value. Only bpo:permittedStepSize is not substituted by properties from existing ontologies.
For complex attribute values, schema:value is re-used for interval values and all classes (bpo:List2d, bpo:Entry2D, and bpo:Interval are defined as subclasses of schema:StructuredValue. Thus, we refrain from re-using scp:AttributeValue and define the bpo:hasList2D, bpo:hasEntry, and bpo:hasInterval properties as subproperties of schema:value, as well. Furthermore, the SolConPro ontology enabled the description of unstructured, two-dimensional lists via Well-Known-Text (WKT), wherefore a new property was introduced. In BPO, we suggest to instead use the terminology as it was proposed in GeoSPARQL (geo:asWKT). Product. Product alignment should focus on generic ontologies as GoodRelations and schema.org. Suitable concepts for alignment are the gr:ProductServiceOrModel and its schema.org counterpart schema:ProductModel. Based on the requirement of free modelling, it is important to note that these classes should be aligned only to the bpo:Product class and not components in general. Thereby, it is not feasible to create broader alignments to GoodRelations. Instead, we propose to model properties of the product itself also in alignment to GoodRelations. Since property modelling for products should not differ to that for components, this cannot be realised fully-automatic by creating subclasses and subproperties.
Alignment to Domain Ontologies. Finally, the BPO should be aligned to domain ontologies as BOT and taxonomies like the bSDD. Considering theoretical applications of the BPO outside of the building domain, we do not recommend to create this alignment on Tbox level. Alternatively, concepts of GoodRelations or schema.org could be used to realise connections between a bot:Element and a bpo:Product. Promising properties are gr:hasMakeAndModel and its schema.org counterpart schema:model that define the type of an gr:Individual or schema:IndividualProduct, each describing a specific, real-life instance of one product type.
Moreover, the alignment to the bSDD is aligned to the schema:additionalType property by establishing the bpo:hasBSDDGUID property as its subproperty. 5
To demonstrate the functionalities of the BPO, a SPARQL-visualizer demo was created and published online7. The visualiser consists of several tabs that are grouped into seven categories: Modelling and classifying products, direct assembly structures, indirect assembly structures using entities, modelling connections between components, adding properties to components, complex property values (Intervals), and complex property values (unstructured, two-dimensional lists).
The demo guides inexperienced users in applying the BPO to describe their own products, beginning with the simple definition of products. It also demonstrates how assembly structures can be described on two levels: directly or via bpo:Entity nodes and how a reasoner can create the direct connection from the indirect one (see Fig. 5, blue: inferred triple). 7 https://madsholten.github.io/sparql-visualizer/?file=https:%2F%2Fwww.dropbox.com%2Fs %2F33ah5crs4a0a25c%2Fbpo-demo.json
Furthermore, the demo demonstrates how connections between entities can be modelled and how properties can be modelled. The latter also includes examples on how complex property values as intervals and two-dimensional unstructured lists can be handled using the BPO. 6
In this paper, we introduced the Building Product Ontology (BPO) which was created after a thorough analysis of the SolConPro ontology and common (product) ontologies. The BPO re-uses suitable and proven concepts from the SolConPro ontology and enhances them with new properties and axioms. It also is closely aligned towards existing (product) ontologies as schema.org, GoodRelations, and SEAS, while an alignment for domain ontologies is proposed on Abox level. With the presented SPARQL-visualizer demo, the BPO's concept is proven and at the same time, users and other researchers are supported in applying the BPO for their own needs.
However, the application of the BPO for describing real products must be extended further. Since the BPO is based on the SolConPro ontology, building products that were modelled using the SolConPro ontology can also be described by the BPO, but these products are limited to multi-functional facade components. Thus, in future work, the utilisation of the BPO for building products from a more general perspective is of high importance. Also, the connection of BPO product descriptions to the products' geometry descriptions via the OMG and FOG ontologies needs to be evaluated.
As the scope of BPO is more precise than the one of the original SolConPro ontology, some concepts of the latter are not re-used in BPO. With the goal of creating modular ontologies that can be adapted and re-used in as many scenarios as possible, the left-over concepts - especially those dealing with parametric dependencies - should be revisited and used as a basis for a modular and more universal ontology with a scope focused on parametric dependencies or equation only. 7
This work is part of the research project EnOB: SCOPE, founded by the German Federal Ministry for Economic Affairs and Energy (BMWi). The concepts of the ontology were developed in collaboration with Fraunhofer Institute for Solar Energy Systems ISE and Ed. Zublin AG and implemented by the authors of this paper.