Skip to content

modify range of has characteristic #862

@wdduncan

Description

@wdduncan

I've noticed the following scenario (included in the attached ontology) creates an unsatisfiable class.
Suppose you have a following classes (indicated in bold) defined by the associated axioms:

  • material entity
    • glass: has characteristic some fragility
  • disposition
    • fragility: characteristic of some material entity
  • process
    • shattering: has characteristic some fragility

When you reason in HERMIT, shattering is unsatisfiable. Explanation:

shattering SubClassOf Nothing

The issue is that since characteristic of is functional, the characteristic is inferred to be both a continuant and occurrent. I know that realizes is the relation to use between a process and disposition. However, a student I was working with did not know this and managed to create a similar situation. The student was reasoning ELK, which won't catch this error, and assumed it was reasonable to have disposition as a characteristic of a process.

Do we want to modify the has characteristic relation to either allow for this kind scenario or restrict the range to exclude realizable entity?

We can remove the functional / inverse functional properties characteristic of / has characteristic relations. I suspect some won't like this. I can see why it makes intuitive sense for characteristic of to be functional. However, someone may have a counter example of why it should not be functional.

I tested restricting the range to exclude realizable entity by creating two custom relations (see attached file) named my_characteristic_of and my_has_characteristic. The range of my_has_characteristic is defined as:

'specifically dependent continuant' and (not ('realizable entity'))

And defined the following classes:

  • material entity
    • salt
  • disposition
    • solubility: my_characteristic_of some salt
  • process
    • dissolving: my_has_characteristic some solubility

Using HERMIT, this determines the class dissolving to be unsatisfiable. The advantage of this approach (perhaps) is that the reason for the unsatisfiable class is more clear.

Image

Interestingly, ELK will also determine the class to be unsatisfiable if you use version 0.6.0.

Of course, the relations can still be defined as functional / inverse functional.

ro-error copy.ofn.txt

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions