inheres in at some time URI re-used with different meaning

[GoogleCodeExporter]

We had been using BFO_0000052 for inheres_in (atemporal) and BFO_0000053 for 
bearer_of. These are declared inverses in RO.

BFO2 has re-used these URIs for relations with different semantics - 
inheres-in-at-ALL-times and bearer-of-at-SOME-time.

Complicating the picture, these are *not* declared as inverses, but they 
probably *should* be:
http://code.google.com/p/bfo/issues/detail?id=144

If this axiom is added to BFO2, then at least the atemporal and temporalized 
forms sharing the same URI will be the same in terms of their basic OWL axioms.

However, they are *not* the same at the FOL level, and we must be *very* 
careful about overloading the IRIs. The differences will probably leak into the 
OWL.

E.g.

'human with parkinsons' EquivalentTo human and BFO_0000052 some 'PD'

This is obviously *not* correct with the BFO2 at-some-times reading (in fact 
it's not clear that this is allowed in BFO2 since the LHS is non-rigid). 
However, we make statements like this all the time with the atemporal relation, 
intending a RO2005-style reading (see critique for details).

I think it's very dangerous to re-use the same URIs. It would be safer if BFO2 
were to use different URIs than the ones already in use.

Or perhaps this notion of URI sharing will not work. Maybe RO should just mint 
RO IDs for these relations if we can't have a guarantee that the same URI won't 
be reused with a different meaning.

See also:
http://code.google.com/p/bfo/issues/detail?id=163

Original issue reported on code.google.com by cmung...@gmail.com on 24 Apr 2013 at 7:15

• Blocked on: #144

[GoogleCodeExporter]

Issue 81 has been merged into this issue.

Original comment by mcour...@gmail.com on 24 Apr 2013 at 8:15

[GoogleCodeExporter]

There is a typo in the above. I said:

 * human with parkinsons' EquivalentTo human and BFO_0000052 some 'PD'

I meant

 * human with parkinsons' EquivalentTo human and BFO_0000053 some 'PD'

When using the labels from RO this says

 * human with parkinsons' EquivalentTo human and 'bearer of' some 'PD'

When using the labels from BFO2 this says

 * human with parkinsons' EquivalentTo human and 'bearer of at some times' some 'PD'

Clearly it's problematic to overload the URI with these two different senses.

Original comment by cmung...@gmail.com on 24 Apr 2013 at 9:35

[GoogleCodeExporter]

Here is another example. We may wish to say

  (bearer_of some open) DisjointWith (bearer_of some closed)

(e.g. open or closed heart valves)

This is the kind of axiom that is very useful to have for error checking. If we 
end up with an interpretation in the spirit of the original RO paper then this 
is perfectly justifiable.

However, if we overload the URIs then in BFO2 we end up saying:

  (bearer-of-at-some-time some open) DisjointWith (bearer-of-at-some-time some closed)

Because the some-times form is weaker, the overall axiom is stronger when used 
with a disjointness axiom. In fact too strong - the above axiom is patently 
false for any object that can switch state like a heart valve.

In summary, it is plainly very wrong to try and re-use the same URI for the 
atemporal and temporalized forms here

Original comment by cmung...@gmail.com on 24 Apr 2013 at 9:40

[GoogleCodeExporter]

I don't see how "Clearly it's problematic" . In the actual case of a disease, 
'bearer of at some times" is a reasonable interpretation of 'bearer of' -- it's 
certainly not 'bearer of at all times.'  I could imagine a more specific 
relation for an incurable disease like PD (something like bearer of 
continuously from some time until death), but that would just be a subclass of 
'bearer of at some time'.  What is the clear problem here?  Can you be more 
explicit about some incorrect inference or other consequence?  

Original comment by HunterOn...@gmail.com on 24 Apr 2013 at 9:43

[GoogleCodeExporter]

The disjoint example might show a difference, *if* you can show that your 
example is interpretable in ro2005ish semantics. However as stated you can't 
have a heart with open or closed valves - since you can only make atemporal 
statements either the valve is open or it isn't.  No change is available. 

Remember, the ro semantics are all-time, and here generic versus specific won't 
help. 

Regarding the desirability of such error checking constraints, I agree and will 
think about how to enable such. 

Original comment by alanruttenberg@gmail.com on 24 Apr 2013 at 10:45

[GoogleCodeExporter]

Hi Larry

The curability issue is a bit of a sidetrack. Let's switch to
influenza.

The standard pre-BFO2-OWL approach is to say something like this:

 [1] Human-with-flu EquivalentTo human and 'bearer of some 'infected-with-flu'

And assume a RO-2005 type interpretation (glossing over a lot here,
see Niels' and Stefan's paper for more) - the statement is true at any
given moment of time. If you're the bearer of a flu infection at t,
then you're an instance of human-with-flu at t. This is different than
at-all-times (which would be incorrect - most people can gain or lose
the infected status, as you point out), and -- crucially -- different
from at-some-times. This is because times have to be the *same* on
either side of the equivalence predicate for it to work, it's not just
at any time.

In fact if we are to switch out the relation to the BFO2-OWL
at-all-times we have:

 [2] Human-with-flu EquivalentTo human and 'bearer of at some time'
     some 'infected-with-flu'

According to the BFO2-OWL release notes this is expanded to:

instance_of(i,Human-with-flu) <-> 
  instance_of(i,Human) &
  exists t : [ instance_of(d,Infected-with-flu)
               bearer_of(i,d,t) ]

Which only makes sense if we interpret

  instance_of(i,Human-with-flu)

As being

  exists t & instance_of(i,Human-with-flu,t)

But in fact BFO2-OWL doesn't support temporal instantiation /
non-rigid classes. 

I can provide a more rigorous treatment in FOL with proofs, but it
might be better if you first look over my critique where a lot of this
ground is covered.

The TR approach and the AR have different ways of interpreting the
relations, which is why we get into trouble if we mix.

Let's take another example

[3]  (bearer_of sick) DisjointWith (bearer_of healthy)

This is biologically valid if we assume the statement to be true for
any given moment (I am never both sick and healthy at the same time -
and let's just assume a simple binary model of sickness here for
simplicity). I have a neeed to make statements like this.

What happens if we switch out the relations behind the schemes to be
the BFO2-OWL ones, which are supposedly equivalent?

[4]  (bearer_of-at-some-times sick) DisjointWith (bearer_of-at-some-times 
healthy)

This is contradicted by most people. There are plenty of examples of a
human h who is sick at t1 and healthy at t2.

The bottom line is that I don't want my statements of type [3] to be
read as [4], which is wy it's crucial to use a different ID/URI for
the at-some-times form and the atemporal form.

Original comment by cmung...@gmail.com on 25 Apr 2013 at 12:20

[GoogleCodeExporter]

Alan: re "The disjoint example might show a difference, *if* you can show that 
your example is interpretable in ro2005ish semantics"

That's the plan. Need to not confuse the relations in the interim.

Original comment by cmung...@gmail.com on 25 Apr 2013 at 12:25

[GoogleCodeExporter]

There is damage that is done by making relations different - it makes 
interoperation less likely. Therefore a balanced decision needs to be made when 
making such decisions. In the case of bearer of, there was general agreement on 
the interpretation of bearer-of, temporally. You wish to do something that has 
a deleterious effect on the basis of a maybe. I believe the example you have 
given is wrong. The assertion 

(bearer-of some open) disjoint-from (bearer-of some closed) 

is not a statement that would be correct by RO2005ish semantics. That's because 
an ROish semantics would not make quantify bearer-of as for all times, as this 
is by far the less common case, and because qualities, by nature are the sorts 
of things that are supposed to be gained or lost in change.

That it is "useful" or that you might find some *different* interpretation in 
which it is correct, brings insufficient benefit considering the downside - 
that users will then be forced to make a decision about which term to use, 
without having any factual basis for doing so.

Take the has-participant definition from RO2005. It uses some-time 
quantification

P has_participant C = [definition] for all p, if Pp then there is some c, t 
such that Cct and p has_participant c at t.

Bearer of, at the class level would have this pattern.

C bearer_of Q = [definition] for all c, if Cc then there is some c, t such that 
Qqt and C bearer_of q at t.

Under this interpretation, "ROish", the statement

(bearer_of some Open) disjointFrom (bearer_of some Closed) 

is false. 

Even in the case that the at-all-times class-level relation was defined, for 
example to record that a type has a rigid determinate, (e.g. all material 
entities have some mass at all times), the case would adequately be handled the 
by the relation bearer_of at all times.

In summary, the motivating example is semantically incorrect. The choice of 
temporal qualification of bearer_of as at-some-time is consistent with the 
RO-2005 style of definitions, and the use case motivating the example is 
adequately handled by the current temporal relations.

Original comment by alanruttenberg@gmail.com on 25 Apr 2013 at 3:58

[GoogleCodeExporter]

Is there any way in BFO2 to record that a heart valve may not be simultaneously 
open and closed or that a person may not simultaneously be an adult and a 
child.  If so, how?

This seems to me to be what Chris's disjointness axiom is attempting to express.

Original comment by dosu...@gmail.com on 25 Apr 2013 at 4:29

[GoogleCodeExporter]

All this pain seems to me to result from our inability to make quantified 
statements over variables (a la FOL), and forcing some of the most critical 
quantifications into places where they can have unfortunate consequences.

The Disjoint-from bearer argument wants to express that there is no time when a 
heart valve is both open and closed.  No combination of bearer-at-some-time 
assertions can do that, because there is no way to say the "some" time is the 
same one in both statements.

Is there some reason that we can't make the existing atemporalized relations 
into ternary relations that make the time explicit, at least at the instance 
level?  Then it would at least be possible to express the open/closed 
disjointness.  Would that satisfy both sides?  

Original comment by HunterOn...@gmail.com on 25 Apr 2013 at 5:55

[GoogleCodeExporter]

To Answer David:

Agreed. I think it would be expressed as the none overlapping of parts of life 
of the heart during which each quality obtains. I have another relation I was 
going to introduce in the next iteration to express this sort of thing- roughly

Q quality-of-during CHP

Where q is a quality and CLP is a continuant history part. 

We want to say, then, that there are no parts of a hearts history such that for 
one open quality-of-during and also closed quality-of-during

I'll be happier when there's a worked example, but hopefully the above shows 
that there is a plausible strategy. 

To Answer Larry.

Attempts thus far seems to make us lose too much of the inference we find 
useful in OWL. But suggestions on how to do this are welcome. But see what you 
think of the above, which effectively relies on overlaps, something we can 
(almost) do in OWL.

Original comment by alanruttenberg@gmail.com on 25 Apr 2013 at 6:41

[GoogleCodeExporter]

Alan: "In the case of bearer of, there was general agreement on the 
interpretation of bearer-of, temporally"

I wasn't aware of this

Alan: "(bearer-of some open) disjoint-from (bearer-of some closed) 
is not a statement that would be correct by RO2005ish semantics. That's because 
an ROish semantics would not make quantify bearer-of as for all times, as this 
is by far the less common case, and because qualities, by nature are the sorts 
of things that are supposed to be gained or lost in change.
"

Of course qualities can be gained or lost. It does not follow from this that 
the statement would be incorrect. The fact of the matter is that bearer-of is 
not in the RO2005 paper, so there's no basis for your claims. Had it been, it's 
not necessarily the case that it would have been at-some-times. Quantification 
of the statement at all times is the more useful (note: note the same as an 
at-all-times TR). E.g. all t : instance_of(i,Human-with-flu,t) -> exists d 
instance_of(d,has-flu,t) & bearer_of(i,d,t). Note that gain or loss is not an 
issue here, since we have a non-rigid class.

This documentation is missing from the existing atemporal object property 
(partly because these relations have been living in limbo for the last year), 
although all usage has been in this sense. I will add clearer docs, together 
with a default all-t statement-level quantification for all C-C statements. 
This will clearly differentiate the meaning from the BFO2 relation.

With regards to my original request - I now think it's best if BFO_0000052 is 
ceded to BFO2 and we mint a new RO ID for the atemporal relation, and transfer 
all current usages across.

Original comment by cmung...@gmail.com on 25 Apr 2013 at 11:13

[GoogleCodeExporter]

Chris, you missed important points. First, either contemplated sense of the 
term you want here are available in the TR. Second, the example you gave was 
flawed under any interpretation. Third, the issue of non-rigid classes is 
orthogonal. The TR relations are agnostic to this distinction.  What is needed 
for that is not extra relations, but a plan for a working embedding in owl. 
There are two candidates and I'm confident we will arrive there. There is no 
plan for bfo1 owl to accommodate that at all. 
My conclusion remains that, at least for a subset of relations including bearer 
of and participates in, minting new terms is not justified from a technical 
point of view, as the temporal relations satisfy will work unproblematically. A 
choice to use other relations for foundry ontologies would be damaging, would 
raise my objection and would need to be mediated by the coordinators and 
operations groups. 

This is quite distinct from the situation with part of, where although there 
are still damages, there is more justification for taking an alternative route. 

Original comment by alanruttenberg@gmail.com on 26 Apr 2013 at 1:11

[GoogleCodeExporter]

"First, either contemplated sense of the term you want here are available in 
the TR."

You haven't demonstrated this. And we keep straying from the point. The 
original point was that BFO_0000053 was re-used with a different meaning from 
how we have been using BFO_0000053. You may not like how we have been using it, 
you may think there are problems inherent in any alternative to TRs, but that 
doesn't alter the fact that it was reused with your interpretation.

In the course of this discussion I have come to accept this. The only option 
left if we are to keep using the bearer-of relation without committing to the 
TR strategy is to create a new relation.

"Second, the example you gave was flawed under any interpretation."

Demonstrate this.

"A choice to use other relations for foundry ontologies would be damaging, 
would raise my objection and would need to be mediated by the coordinators and 
operations groups."

I have been trying to avoid this for the last year. However, I see no other 
way. The choice is (1) TRs (2) some alternative to TRs. Given that you have 
blocked (2) from BFO2, the only option is to make the alternatives somewhere 
else.

Original comment by cmung...@gmail.com on 26 Apr 2013 at 3:31

[GoogleCodeExporter]

> "First, either contemplated sense of the term you want here are available in 
the TR."

Chris: You haven't demonstrated this.

Alan: We have only touched on the all-times or some-times ro-ish 
interpretations? Each is straighforward because there is no issues of 
genericity. Please be specific about where you think I've failed.

Chris: And we keep straying from the point. The original point was that 
BFO_0000053 was re-used with a different meaning from how we have been using 
BFO_0000053.

Alan: I'm sorry, I just don't know what you are talking about. You can a 
supposed example of why we didn't have the same meaning. I've shown that the 
example is bad. All you've demonstrated is that you aren't even clear about 
what the possible meanings it *could* have, never mind the one you propose it 
*does* have.

Chris: You may not like how we have been using it, you may think there are 
problems inherent in any alternative to TRs, but that doesn't alter the fact 
that it was reused with your interpretation.

Alan: You don't *have* an alternative. All you have is criticism of the TR 
approach and loose appeals to the undefined relations you are suggesting 
sometimes leading to acceptable entailments.

Chris: In the course of this discussion I have come to accept this. The only 
option left if we are to keep using the bearer-of relation without committing 
to the TR strategy is to create a new relation.

Alan: You've come to your conclusion, which I believe is misplaced. I've come 
to the conclusion that I don't know what it takes to convince you and so this 
becomes a coordination issue.

"Second, the example you gave was flawed under any interpretation."

Chris: Demonstrate this.

Alan: I did in my comments above. You asked for detailed responses. I gave you 
that. The other readers seem to get it. I think it is your turn to show why I 
haven't.

"A choice to use other relations for foundry ontologies would be damaging, 
would raise my objection and would need to be mediated by the coordinators and 
operations groups."

Chris: I have been trying to avoid this for the last year. However, I see no 
other way. The choice is (1) TRs (2) some alternative to TRs. Given that you 
have blocked (2) from BFO2, the only option is to make the alternatives 
somewhere else.

You haven't tried hard enough. Your only offer is to accept the status quo of 
relations with no BFO interpretation. I haven't blocked (2) - there just hasn't 
been any alternative offered that comes with a proper BFO consistent FOL 
interpretation. You keep saying you can create logical definitions that are 
consistent with P1. Do so. Then we'll have an alternative, and if it works I 
will be very happy. But you can't keep blocking with an alternative whose only 
basis is your opinion that it works well enough and that you *should* be able 
to, sometime in the future, come up with a BFO consistent semantics.

Original comment by alanruttenberg@gmail.com on 26 Apr 2013 at 4:22

[GoogleCodeExporter]

the temporally qualified inheres_in and bearer_of would be inverses if we did 
not have specific dependence. 
Action:
1) Is specific dependence between processes and continuants equivalent 
(logically) with has-participant. 
2) What would go wrong if we only had inheres_in and not specifically depends 
between dependent continuants and independent continuants.

If answer to both is that nothings is gained by specifically depends on either 
a) Rename inheres_in specifically depends on (but keep as alternative term)
or
b) Keep only inheres_in 

Note: ro2005 interpretation of inheres_in would make inheres_in support 
migration of qualities, which is specifically disallowed, so that is not a 
correct interpretation.

Barry suggests that we keep specifically depends on to allow for Chris "broader 
use of" inheres in. 
Alan considers that (some polite synonym for: 'nonsense')

Original comment by alanruttenberg@gmail.com on 26 Jun 2013 at 7:44