City located_in 'Constitutive State' generates contradiction

[jonathanvajda]

A Local Administrative Region (e.g., a City) that is located_in some First-Order Administrative Region (e.g., Constitutive State) yields an inconsistency with HermiT reasoner.

It seems to be due to the axiom on First-Order Administrative Region's, that every such FOAR is "part_of some 'Domain of A Country' "

When the relation 'part of' is used instead of 'located in', no such inconsistency is generated.

Yet the documentation for CCO modeling information (I believe attached to 1.3) the diagrams use "located in" between instances of bfo:Site such as City to State, e.g. Tucson located_in Arizona.

Steps to generate this issue:

• create an instance, type First Order Administrative Region
• create an instance, type Local Administrative Region
• assert the objectProperty relation 'located in' between the second instance and the first instance.
• Start reasoner --> boom! contradiction

[swartik]

I think the problem is the contained in super-property assertion:

located_in o part_of SubPropertyOf contained_in

The domain of contained_in is a material entity, so the Local Administrative Region individual is inferred to be a material entity.

This may be a BFO issue. The three properties in question are from RO, not CCO.

[jonathanvajda]

I think the problem is the contained in super-property assertion:

located_in o part_of SubPropertyOf contained_in

The domain of contained_in is a material entity, so the Local Administrative Region individual is inferred to be a material entity.

This may be a BFO issue. The three properties in question are from RO, not CCO.

Interesting point. Perhaps we should raise it up to the level of RO.

As for CCO, if the part_of axiom is taken out of FOAR (first order admin region), then no contained_in relation is inferred, and that also fixes it. But then again, "Constitutive State" should have the axiom (given its name) and we would face the same issue.

Anyone know when this would have broken? E.g., did CCO 1.3 have (or inherit) this issue all this time?

[johnbeve]

This may be a BFO issue. The three properties in question are from RO, not CCO.

BFO ≠ RO.

I think the problem is the contained in super-property assertion:

Agreed:

[mark-jensen]

@jonathanvajda Great catch! Thank you. As both @swartik and @johnbeve point out, the problem wrt reasoning is the odd way RO handles contained_in (CI) and located_in (LI) and part_of (PO). PO is transitive. CI is not.

x CI y is a shortcut for x LI z & z PO y
but
x LI z is a shortcut for x LI q & q PO z
so
x CI y means that x LI q & q PO z & z PO y
and so on ...

The metadata for CI says "containment is location without parthood". Really? How? I really don't like this. Makes me squirm in my seat. Which may explain #693 & #739. RO has just recently obsoleted CI!

CCO is not w/o fault here though. In our documentation we recommend using LI to connect subtypes of bfo:sites, yet our axioms for those subtypes, such as FOAR, use PO.

++1 for @johnbeve for noting that BFO is not RO. With the upcoming adoption of BFO2020 and a core set of non-temporal relations, we will be resolving some of these headaches.

In the short-term, the best fix is probaby to delete all those axioms for the Admin Regions that use PO.

[jonathanvajda]

Hey Mark,

All makes sense. Good tracking down RO's deprecation. Does this mean CCO will deprecate likewise? It would solve without removing axioms.

[jonathanvajda]

Following up:

It seems like your proposed solution was to delete the axioms for first-order admin region, but

• the axiom comes from the definition, and so if it is removed it seems like that is a sufficient condition for deprecating the term
• the axiom is fine, if ERO deletes the "contains"/"contained in" relation which as you noted was obsoleted in RO

Wouldn't deprecating the problematic RO relations be preferred solution in order to close this ticket?

[cameronmore]

Will be fixing in the bfo2020-core branch