Conceptualisation

Conceptualisation is the most important activity in ontology development. The outcome of this activity is a specification of the ontology components which should reflect a set of terms produced in the Knowledge Acquisition phase. In what follows, the OSIS ontology components and taxonomy are discussed.

OSIS Ontology Components

Using the key concepts identified in the Knowledge Acquisition activity, the OSIS ontology components are defined below.

The concepts are distinguished between those which are broad and abstract, for example, IndicatorSet and Indicator which we model as superclasses in one design candidate of OSIS, and those which are specific and thus form the subclasses in another design candidate of OSIS. Superclasses are inherited by the subclasses using is-a relation. Additionally, classes may have attributes that complement them. Examples of attributes are PeriodOfTime and Publisher. Relations express the interaction between two classes of associates with has-a relation, such as hasCategory and hasReference. Individuals include all indicators of the sustainability systems, such as EC1 and EC2 in GRI and 1.1. Production Based CO2 Productivity and 1.2. Demand-based CO2 Productivity in OECD. In addition, indicator sets can be represented as constants based on which ontology design candidate – specific or generic – is chosen. We skip the step of defining axioms due to the small size of our ontology. The next step after identifying the ontology components is developing the taxonomy.

OSIS Taxonomy

We continue by developing OSIS taxonomy, which represents a hierarchical structure of is-a relations between concepts. In a taxonomy, there is no distinction between the ontological status of conceptual entities, for instance, whether they ought to be represented by classes or individuals, or related by generic attributes or specific subclass relations. Given the GRI and OECD taxonomies presented in Section 2.9.1 and related Figures 2.4 and 2.5, we notice

OSIS Design Process 77

that the key concepts of sustainability development in GRI indicator set are presented in six standard categories (disclosures) and their various subcategories (aspects). Indicators are at the bottom of this hierarchy. Similarly, the OECD indicator set illustrates the key information in five main categories that include two levels of subcategories (themes). Like GRI, indicators are at the bottom of the hierarchy structure.

The OSIS taxonomy is based on the hierarchical structure of the GRI and OECD indi-cator sets, in which themes and aspects are replaced with generic concepts of category and subCategory. The indicators are also represented at the bottom of the hierarchy.

On the other hand, in designing OSIS, we emphasise interoperability and reusability features which give the higher level distinction of concepts which help one to understand the concepts at the lower level. Additionally, since ontologies and knowledge bases are not widely used in the domain of sustainability, these requirements account for the most important features for any developed ontology associated with this area. In developing OSIS, we address these with the use of ontology design patterns (ODPs). A complete literature of ODPs is presented in Section 2.7. The ontology patterns that are used in OSIS structure are presented below.

Ontology Design Patterns Used in OSIS

Given the identified key concepts and relations and OSIS taxonomy, the relation between abstract concepts may have various interpretations from different perspectives. As illustrated in Figures 4.2 and 4.3, we notice that specific indicator systems, taken from organisations such as GRI and OECD, should be specified in relation to abstract concepts of IndicatorSet and Indicator. In other words, one of the design problems is the association of Indicator with IndicatorSet. This affects the relations of other concepts such as Category, Description and Reference. The question here is how to determine the relations between IndicatorSet and Indicator concepts to be represented as classes, subclasses or instances? Solving such design problems ideally should reflect the requirements of the final ontology design.

To address the aforementioned modelling problems, we use the Value Partition (VP)

pat-OSIS Design Process 78

IndicatorsSet

Indicator

EC1 GRI

OECD UN

Class Individual

Relation InstanceOf

is-a

has[…]Indicator belongsTo[…]

belongsTo_GRIIndicatorSet has_GRIIndicator

Figure 4.4: Value Partition - Pattern 1

terns, described in Section 3.1.3. Two possible ontology models following the VP patterns are detected.

• From the viewpoint of explicitness, it is usefulness to specify particular system indica-tors as subclasses GRI of a superclass (for example IndicatorSet) (Pattern 1). This design supports a specific representation of the domain problem and reflects detailed views of each system indicator. This view is more detailed to include direct references to specific indicator sets, which is called Specific Ontology for Sustainability Indicator Sets or SOSIS. Figure 4.4 features our solution for the second design problem.

• From the viewpoint of reusability, we also see that system indicators can be included as instances of IndicatorSet and an Indicator class is further linked by a particular relation (for example belongsToIndicatorSet) (Pattern 2). Figure 4.6 illustrates our solution for the second design problem. This view is more broader to cover sustainabil-ity indicators’ key information with no reference to any particular organisations and is called Generic Ontology for Sustainability Indicator Set or GOSIS.

Another way to compare the two design candidates is to look at their UML diagrams

OSIS Design Process 79

OECD IndicatorSet dc:title String dc:text String dc:type Description dc:format String

Description dc:title String dc:text String dc:type Category

Category OECD ThemeGRI AspectGRI DescriptionOECD DescriptionGRI IndicatorSet

is-ais-a

is-ais-a GRI Compilation GRI Definition GRI Documentation

GRI Relevance OECD InformationOECD Documentation

is-a is-a is-a is-a is-ais-a

dc:title String dc:text String dc:type Issue osis:hasObjective String

Issue gri:hasCompilation gri:hasDefinition gri:hasDocumentationgri:hasRelevance

gri:hasAspect oecd:hasTheme oecd:hasDocumentationoecd:hasInformation

osis:hasIssue

osis:relatedToIndicator

IndicatorSet dc:title String dc:text String dc:type IndicatorSet osis:numberOfIndicator Integer osis:numberOfcategory Integer osis:numberOfsubCategory Integer is-ais-a Figure4.5:UMLDiagramofSOSISDesignUsingValuePartitionPattern1

OSIS Design Process 80

IndicatorSet Indicator

EC1 belongsToIndicatorSet

belongsToIndicatorSet OECD GRI

َUN

hasIndicator

hasIndicator Class

Individual

Relation InstanceOf

Figure 4.6: Value Partition - Pattern 2

which are built upon the aforementioned Patterns of VP shown in Figure 4.5 and 4.7 for SOSIS and GOSIS designs respectively.

Furthermore, the rationale of the two design candidates are in relation to the requirements defined in the Specification activity (Section 4.1.1). We are unable to present a unique ontol-ogy model, which addresses both requirements. Instead, we suggest the use of two ontolontol-ogy design models, in which each model captures an aspect of the requirements: Supporting indi-cator systems (i) precisely and intuitively (SOSIS) and (ii) generally and reusability (GOSIS).

The details of formalising the design candidates are as follows.