Policy on inverse relations about bfo HOT 16 OPEN

From [email protected] on January 13, 2012 11:14:38

Labels: -Type-Defect Type-BFO2-design

from bfo.

From [email protected] on January 13, 2012 11:43:43

My feeling is that the BFO2 reference should take care of issues like that, especially we need an outline of how to check whether inverse relations do make sense from the ontological perspective.

If we have a jungle of inverse relations in the OWL version without giving account for them in the reference than the reference is not the reference.

So, we (the BFO OWL group) should be able to propose inverse relations to the reference, but the reference should outline a strategy for how to tackle the issue (I discussed that with Alan briefly and took the liberty to ask Barry whether this was on the agenda of the creators of the reference.

from bfo.

From [email protected] on January 13, 2012 17:40:25

I vote for always declaring the inverse object property.

I cannot imagine an inverse object property that would not make sense. There is no difference between

ObjectPropertyAssertion(P A B)
ObjectPropertyAssertion(inverseOf(P) B A)

The order is simply a matter of convenience, there should be no ontological implications beyond the OWL semantics.

Waiting for these to go into the reference document just seems to add bottlenecks to an already complicated and slow process. Will the reference document also have all the synonyms, examples of usage and other things that are more suited to modeling in the OWL?

from bfo.

From [email protected] on January 14, 2012 10:26:54

"Will the reference document also have all the synonyms, examples of usage and other things that are more suited to modeling in the OWL?"

IMO
Examples of usage for sure since they speak to the correct interpretation of the terms.
Synonyms not, as we can't expect that these are static
Others: Address on a case by case basis

With all of these it seems the decision should be done with a mind to consistency. Elements that will be shared between FOL and OWL versions should be in the reference whenever possible would be my inclination.

Regarding inverses in OWL, note that there is no need to actually name inverses, as any inverse can be used by using the inv() operator.

from bfo.

From [email protected] on January 16, 2012 12:48:05

I vote for always having inverses, following a consistent naming policy.
Synonyms only if needed for linking back to OBO RO.

from bfo.

From [email protected] on January 16, 2012 12:48:20

I'll handle this one.

Owner: [email protected]

from bfo.

From [email protected] on January 16, 2012 12:48:39

I'll handle this one.

from bfo.

From [email protected] on January 16, 2012 12:48:49

I'll handle this one.

from bfo.

From [email protected] on January 16, 2012 12:48:51

I'll handle this one.

from bfo.

From [email protected] on January 16, 2012 12:48:54

I'll handle this one.

from bfo.

From [email protected] on April 29, 2012 02:11:28

Inverse relations included in current working BFO 2 in OWL.

Status: Done

from bfo.

From [email protected] on May 01, 2012 01:06:04

Put back to started pending decision process for closing issues.
"current working BFO 2 in OWL" is a non-referring expression.
The intended referent is, https://code.google.com/p/bfo/source/browse/trunk/src/ontology/owl-schulz/bfo.owl r215

Status: Started
Labels: -Type-BFO2-design Type-BFO2-OWL

from bfo.

From [email protected] on May 25, 2012 10:30:13

In the meeting of May 25 we decided we would have these, asking Barry to add them to the reference.

from bfo.

From [email protected] on July 11, 2012 13:57:59

What about temporalized object properties not in the reference?

For example, the current owl-group bfo.owl lacks inverseProperties axioms for part-of-c-at-all-times. What is the policy here? Is this a temporary omission or intended for final release?

I think these OPs should be named and declared inverses, somewhere. This presumably requires a new linguistic qualifier. E.g.

InverseOf(
part-of-continuant-at-all-times
has-continuant-part-at-all-times-that-part-exists
)

I think many users of BFO would be surprised not to find this standard mereoligical inverse pairing.

Also, if the generic part relations are to go in RO (is this the plan? document? sorry haven't had time for the calls), I propose

BFO:0000050 'is part of' replaced by--> RO:0000050, "part_of"
BFO:0000051 'has part' replaced by--> RO:0000051, "has_part"

SubPropertyOf(
bfo:continuant-part-of-at-all-times ro:part_of
)

SubPropertyOf(
bfo:has-continuant-part-at-all-times-that-part-exists ro:has_part
)

And with additional expressivity (outside DL):

ro:part_of
equivalentTo
bfo:continuant-part-of-at-all-times OR
bfo:occurrent-part-of

ro:has_part
equivalentTo
bfo:has-continuant-part-at-all-times-that-part-exists OR
bfo:has-occurrent-part

from bfo.

From [email protected] on July 11, 2012 20:54:59

Comments in line:

What about temporalized object properties not in the reference?

For example, the current owl-group bfo.owl lacks inverseProperties axioms for part-of-c-at-all-times. What is the policy here? Is this a temporary omission or intended for final release?

It is a tentative choice for the final release. The inverse issue is discussed at https://code.google.com/p/bfo/issues/detail?id=73 https://code.google.com/p/bfo/issues/detail?id=49#c2 It is thought by some that dealing with this adds a large number of named properties to an already long list and has the potential to induce more confusion, and on the other hand those relations can always be inverted in OWL code anonymously.
The WG hasn't made a final decision on this.

I think these OPs should be named and declared inverses, somewhere. This presumably requires a new linguistic qualifier. E.g.

InverseOf(
part-of-continuant-at-all-times
? has-continuant-part-at-all-times-that-part-exists
)

I think many users of BFO would be surprised not to find this standard mereoligical inverse pairing.

There are conflicting goals, as described above. We'll have to decide and I note your preference.

Also, if the generic part relations are to go in RO (is this the plan? document? sorry haven't had time for the calls), I propose

BFO:0000050 'is part of' replaced by--> RO:0000050, "part_of"
BFO:0000051 'has part' replaced by--> RO:0000051, "has_part"

SubPropertyOf(
bfo:continuant-part-of-at-all-times ro:part_of
)

SubPropertyOf(
bfo:has-continuant-part-at-all-times-that-part-exists ro:has_part
)

I don't think that's a good idea. For one thing, has_part in OBO is temporally qualified (class level) on the first, not the second argument. Other than that precedent there is no reason to choose one relation over the other. I think you are better off dropping that they are inverses.
In any case, BFO:0000050 and BFO:0000051 although marked as obsolete in my lisp sources, are not in any currently produced artifact.

And with additional expressivity (outside DL):

ro:part_of
equivalentTo
bfo:continuant-part-of-at-all-times OR
bfo:occurrent-part-of

ro:has_part
equivalentTo
bfo:has-continuant-part-at-all-times-that-part-exists OR
bfo:has-occurrent-part

You can also have (ro:has_part some thing) equivalentClasses (union-of bfo:has-continuant-part-at-all-times-that-part-exists bfo:has-occurrent-part),which is in DL but not as strong at the instance level. But I'm pretty sure that its going to hurt to have the disjunct on a relation that is used everywhere.

I'd rather see, first, some evidence that the approach of defining this relation actually helps - i.e. that using it makes it easy to correctly translate obo files, and that the resultant ontologies can be reasoned over in a useful way.

I'll note that we do not have to decide on naming the inverse relations in order for this proof of concept to be tested, or for a final implementation. The existing OBO is existing OBO. I don't think any new work should be authored using that generic relation.

from bfo.

From [email protected] on July 11, 2012 21:07:34

Not careful enough - the "you can also have" should read:

(ro:has_part some thing) equivalentClasses:
(union-of (bfo:has-continuant-part-at-all-times-that-part-exists some thing) (bfo:has-occurrent-part some thing))

from bfo.