Policy on inverse relations

[GoogleCodeExporter]

BFO2 reference doesn't always define an inverse relation when a relation is 
defined. 
See 
http://groups.google.com/group/bfo-owl-devel/browse_thread/thread/9527351b8a7e2d
58/40117a6afbd3154f?lnk=gst&q=inverse#40117a6afbd3154f

Sense from existing discussion is that always having inverse is desirable.

The proposal is that we always define the inverse. 
Q: Do we duplicate/rewrite documentation?
Q: Do we ask that the inverses are given labels and mention in BFO2 reference?

Original issue reported on code.google.com by alanruttenberg@gmail.com on 13 Jan 2012 at 7:12

[GoogleCodeExporter]

Original comment by alanruttenberg@gmail.com on 13 Jan 2012 at 7:14

• Added labels: Type-BFO2-design
• Removed labels: Type-Defect

[GoogleCodeExporter]

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.

Original comment by MBrochhausen@gmail.com on 13 Jan 2012 at 7:43

[GoogleCodeExporter]

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?

Original comment by cmung...@gmail.com on 14 Jan 2012 at 1:40

[GoogleCodeExporter]

"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.  

Original comment by alanruttenberg@gmail.com on 14 Jan 2012 at 6:26

[GoogleCodeExporter]

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

Original comment by steschu@gmail.com on 16 Jan 2012 at 8:48

[GoogleCodeExporter]

I'll handle this one.

Original comment by steschu@gmail.com on 16 Jan 2012 at 8:48

[GoogleCodeExporter]

I'll handle this one.

Original comment by steschu@gmail.com on 16 Jan 2012 at 8:48

[GoogleCodeExporter]

I'll handle this one.

Original comment by steschu@gmail.com on 16 Jan 2012 at 8:48

[GoogleCodeExporter]

I'll handle this one.

Original comment by steschu@gmail.com on 16 Jan 2012 at 8:48

[GoogleCodeExporter]

I'll handle this one.

Original comment by steschu@gmail.com on 16 Jan 2012 at 8:48

[GoogleCodeExporter]

Inverse relations included in current working BFO 2 in OWL. 

Original comment by janna.ha...@gmail.com on 29 Apr 2012 at 9:11

• Changed state: Done

[GoogleCodeExporter]

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, 
http://code.google.com/p/bfo/source/browse/trunk/src/ontology/owl-schulz/bfo.owl
 r215

Original comment by alanruttenberg@gmail.com on 1 May 2012 at 8:06

• Changed state: Started
• Added labels: Type-BFO2-OWL
• Removed labels: Type-BFO2-design

[GoogleCodeExporter]

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

Original comment by alanruttenberg@gmail.com on 25 May 2012 at 5:30

[GoogleCodeExporter]

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

Original comment by cmung...@gmail.com on 11 Jul 2012 at 8:57

[GoogleCodeExporter]

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
http://code.google.com/p/bfo/issues/detail?id=73
http://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.

Original comment by alanruttenberg@gmail.com on 12 Jul 2012 at 3:54

[GoogleCodeExporter]

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))

Original comment by alanruttenberg@gmail.com on 12 Jul 2012 at 4:07