Issue 19 in bfo: Policy on inverse relations

[b...@googlecode.com]

Status: Accepted
Owner: alanrut...@gmail.com
Labels: Type-Defect Priority-Medium

New issue 19 by alanrut...@gmail.com: Policy on inverse relations
http://code.google.com/p/bfo/issues/detail?id=19

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/9527351b8a7e2d58/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?

[b...@googlecode.com]

Updates:
Labels: -Type-Defect Type-BFO2-design

Comment #1 on issue 19 by alanrut...@gmail.com: Policy on inverse
relations
http://code.google.com/p/bfo/issues/detail?id=19

(No comment was entered for this change.)

[b...@googlecode.com]

Comment #2 on issue 19 by MBroch...@gmail.com: Policy on inverse
relations
http://code.google.com/p/bfo/issues/detail?id=19

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.

[b...@googlecode.com]

Comment #3 on issue 19 by cmung...@gmail.com: Policy on inverse relations
http://code.google.com/p/bfo/issues/detail?id=19

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?

[b...@googlecode.com]

Comment #4 on issue 19 by alanrut...@gmail.com: Policy on inverse
relations
http://code.google.com/p/bfo/issues/detail?id=19

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

[b...@googlecode.com]

Comment #5 on issue 19 by stes...@gmail.com: Policy on inverse relations
http://code.google.com/p/bfo/issues/detail?id=19

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

[b...@googlecode.com]

Updates:
Owner: stes...@gmail.com

Comment #6 on issue 19 by stes...@gmail.com: Policy on inverse relations
http://code.google.com/p/bfo/issues/detail?id=19

I'll handle this one.

[Stefan Schulz]

not clear why googlecode produces this message:

2012/1/16 <b...@googlecode.com>:

> I'll handle this one.

It seems I should not have acknowledged a popup window which
repeatedly shows up...

- Stefan

--

Stefan SCHULZ  (Univ.-Prof. Dr. med.)

Institut für Medizinische Informatik,
Statistik und Dokumentation
Medizinische Universität Graz
Auenbruggerplatz 2/V
8036 Graz (Austria)

http://www.medunigraz.at/imi
http://g.co/maps/aqedt

+43 (0)316 385 16939
+43 (0)316 385 13201

http://purl.org/steschu
mailto:stefan...@medunigraz.at
Skype: stschulz

[  home: Afritschgasse 32/3
[  8020 Graz (Austria)
[  mobile:  +43 (0)699 150 96270
[  http://g.co/maps/m8rau

[b...@googlecode.com]

Comment #8 on issue 19 by stes...@gmail.com: Policy on inverse relations
http://code.google.com/p/bfo/issues/detail?id=19

I'll handle this one.

[b...@googlecode.com]

Comment #7 on issue 19 by stes...@gmail.com: Policy on inverse relations

[b...@googlecode.com]

Comment #9 on issue 19 by stes...@gmail.com: Policy on inverse relations

[b...@googlecode.com]

Comment #10 on issue 19 by stes...@gmail.com: Policy on inverse relations

[b...@googlecode.com]

Updates:
Status: Done

Comment #11 on issue 19 by janna.ha...@gmail.com: Policy on inverse
relations
http://code.google.com/p/bfo/issues/detail?id=19

Inverse relations included in current working BFO 2 in OWL.

[b...@googlecode.com]

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

Comment #12 on issue 19 by alanrut...@gmail.com: Policy on inverse
relations
http://code.google.com/p/bfo/issues/detail?id=19

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