The successful standardisation of protocols made us believe that we should also standardise meaning on the Web. This is a fundamental misconception. (Janowicz and Hitzler, 2013).
Standardising meaning implies to enforce one single, agreed convention on how the syntactic representation and structure of the data or messages shall be semantically interpreted. This approach fails sooner or later, because such standard allows only one single POV, or perspective, on what is relevant to consider (and what not), how we can carve out that particular part of reality (creating one allowed structure), and how such should be represented (prescribing one single syntactic form). Unfortunately, any particular perspective is just one out of many equally legitimate ones; consequently, any POV taken to single out a particular interpretation of reality will fall short for different stakeholders, actors or applications that, by definition, take another perspective on the domain of application.
The SDO community acknowledged this concern, and decided they should take another approach to standardisation. And it did. As described in the UCO Design Document, section 5:
[A facet] it is designed as a general characterizing extension for a domain object (...) [and] serves to enable Duck Typing as described in [Section] 5.1 below and flexible characterization of subclasses of observable objects through combinations of facets
rather than more complex property inheritance via definition directly on observable object subclasses that proved highly problematic in other information standards efforts such as CybOX.
Applying facets is, thus, understood as a design pattern to work around "enforcing strict data typing" and "allow data to be defined by its inherent characteristics" instead. Despite the good intentions, the use of facets have been experienced as additional complication to an already difficult task of engineering an ontology, and the execution of the approach has been problematic. The reason is not laid in the design pattern itself, but in the environment that the design pattern is applied. Whereas the facet design pattern works well in software engineering, it fails to work well in ontology engineering. Why is that, and what can we do to enforce duck typing, allow for different POV and stay away from conflating syntax with semantics?
The Problem
The reason is that although an ontology and a data schemata are both models, they represent very different types of models. A data scheme prescribes how the data should be represented, and any deviation from it will result in failure of the software to process that data. Contrarily, an ontology describes reality, and we can only interpret the description differently than it was intended. Consequently, the schemata and ontologies stand with their back to each other: the ontology looks at the domain of application, trying to describe it; the scheme looks at the system, prescribing how it should behave. For the data, the scheme represents its source of truth whereas for the ontology, reality represents its source of truth. If Boyle's Law (the ontology) were not to accurately describe the pressure of a gas as it gets compressed (the application domain), we would not hold the gas responsible but we would hold the model responsible; if the data fail to match the scheme, the software cannot process them and we hold the data responsible. This makes software engineering and ontology engineering complementary types of modeling. And where the facet pattern has a positive, causal effect on the complexity of software models, it has a detriment effect on ontologies because in that context the causality works the other way.
Requirements
Requirement 1
Requirement 2
Risk / Benefit analysis
Benefits
Risks
Solution suggestion
Specify necessary characteristics only
Ontology engineering is about applying constraints in order to only allow states of affairs in our domain that we intend to describe with the ontology. So we keep the model as generically applicable as possible, and disallow particular interpretations that are not intended. We achieve that by stating the few characteristics that are really necessary for all our applications, resulting in too wide a model for a specific application. Then, by applying constraints, we remove what we don't want to include.
plbt5
commented
2 years ago
Background
Standardising meaning implies to enforce one single, agreed convention on how the syntactic representation and structure of the data or messages shall be semantically interpreted. This approach fails sooner or later, because such standard allows only one single POV, or perspective, on what is relevant to consider (and what not), how we can carve out that particular part of reality (creating one allowed structure), and how such should be represented (prescribing one single syntactic form). Unfortunately, any particular perspective is just one out of many equally legitimate ones; consequently, any POV taken to single out a particular interpretation of reality will fall short for different stakeholders, actors or applications that, by definition, take another perspective on the domain of application.
The SDO community acknowledged this concern, and decided they should take another approach to standardisation. And it did. As described in the UCO Design Document, section 5:
Applying facets is, thus, understood as a design pattern to work around "enforcing strict data typing" and "allow data to be defined by its inherent characteristics" instead. Despite the good intentions, the use of facets have been experienced as additional complication to an already difficult task of engineering an ontology, and the execution of the approach has been problematic. The reason is not laid in the design pattern itself, but in the environment that the design pattern is applied. Whereas the facet design pattern works well in software engineering, it fails to work well in ontology engineering. Why is that, and what can we do to enforce duck typing, allow for different POV and stay away from conflating syntax with semantics?
The Problem
The reason is that although an ontology and a data schemata are both models, they represent very different types of models. A data scheme prescribes how the data should be represented, and any deviation from it will result in failure of the software to process that data. Contrarily, an ontology describes reality, and we can only interpret the description differently than it was intended. Consequently, the schemata and ontologies stand with their back to each other: the ontology looks at the domain of application, trying to describe it; the scheme looks at the system, prescribing how it should behave. For the data, the scheme represents its source of truth whereas for the ontology, reality represents its source of truth. If Boyle's Law (the ontology) were not to accurately describe the pressure of a gas as it gets compressed (the application domain), we would not hold the gas responsible but we would hold the model responsible; if the data fail to match the scheme, the software cannot process them and we hold the data responsible. This makes software engineering and ontology engineering complementary types of modeling. And where the facet pattern has a positive, causal effect on the complexity of software models, it has a detriment effect on ontologies because in that context the causality works the other way.
Requirements
Requirement 1
Requirement 2
Risk / Benefit analysis
Benefits
Risks
Solution suggestion
Specify necessary characteristics only
Ontology engineering is about applying constraints in order to only allow states of affairs in our domain that we intend to describe with the ontology. So we keep the model as generically applicable as possible, and disallow particular interpretations that are not intended. We achieve that by stating the few characteristics that are really necessary for all our applications, resulting in too wide a model for a specific application. Then, by applying constraints, we remove what we don't want to include.