I am building a software for automatically infer unknown gUFO classifications of OWL classes from known classifications from the same OWL ontology - for now, I'm working only with EndurantTypes. Running some tests, I noticed that some classes never had their gUFO classifications fully set because, e.g., they could be SubKinds or Sortals. I concluded that gUFO was projected like this because of the open-world assumption.
However, when talking to Tiago Sales, he told me that the user should set his/her classes as types of the gUFO leaf classes for the Types' hierarchy (Kind, SubKind, Role, Phase, Mixin, Category, RoleMixin, PhaseMixin) and that this was not the case only for the Individuals' hierarchy. I.e., the non-leaf classes in the types hierarchy should be "abstract" (not the best term for open-world).
I tried to verify this information using the documentation, but the only mentioning I could find for this idea was: "The most abstract classes in this structure mostly reflect the taxonomy of individuals.", which is not enough for the conclusion I had before talking to Tiago.
Hence, I propose:
improve the documentation, making clear this intended use, and
create a partition set (owl:disjointUnionOf) for the non-leaf classes that still don't have it in the types hierarchy. For the Endurant types, the classes are:
I am building a software for automatically infer unknown gUFO classifications of OWL classes from known classifications from the same OWL ontology - for now, I'm working only with EndurantTypes. Running some tests, I noticed that some classes never had their gUFO classifications fully set because, e.g., they could be SubKinds or Sortals. I concluded that gUFO was projected like this because of the open-world assumption.
However, when talking to Tiago Sales, he told me that the user should set his/her classes as types of the gUFO leaf classes for the Types' hierarchy (Kind, SubKind, Role, Phase, Mixin, Category, RoleMixin, PhaseMixin) and that this was not the case only for the Individuals' hierarchy. I.e., the non-leaf classes in the types hierarchy should be "abstract" (not the best term for open-world).
I tried to verify this information using the documentation, but the only mentioning I could find for this idea was: "The most abstract classes in this structure mostly reflect the taxonomy of individuals.", which is not enough for the conclusion I had before talking to Tiago.
Hence, I propose: