-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inheres in at some time URI re-used with different meaning #164
Comments
From [email protected] on April 24, 2013 13:15:01 Issue 81 has been merged into this issue. |
From [email protected] on April 24, 2013 14:35:07 There is a typo in the above. I said:
I meant
When using the labels from RO this says
When using the labels from BFO2 this says
Clearly it's problematic to overload the URI with these two different senses. |
From [email protected] on April 24, 2013 14:40:23 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 |
From [email protected] on April 24, 2013 14:43:40 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? |
From [email protected] on April 24, 2013 15:45:32 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. |
From [email protected] on April 24, 2013 17:20:41 Hi Larry The curability issue is a bit of a sidetrack. Let's switch to 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, In fact if we are to switch out the relation to the BFO2-OWL [2] Human-with-flu EquivalentTo human and 'bearer of at some time' According to the BFO2-OWL release notes this is expanded to: instance_of(i,Human-with-flu) <-> 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 / I can provide a more rigorous treatment in FOL with proofs, but it The TR approach and the AR have different ways of interpreting the 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 What happens if we switch out the relations behind the schemes to be [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 The bottom line is that I don't want my statements of type [3] to be |
From [email protected] on April 24, 2013 17:25:50 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. |
From [email protected] on April 25, 2013 08:58:15 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. |
From [email protected] on April 25, 2013 09:29:24 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. |
From [email protected] on April 25, 2013 10:55:48 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? |
From [email protected] on April 25, 2013 11:41:07 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. |
From [email protected] on April 25, 2013 16:13:08 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) 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. |
From [email protected] on April 26, 2013 06:11:55 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. 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. |
From [email protected] on April 26, 2013 08:31:19 "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. |
From [email protected] on April 26, 2013 09:22:11
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. |
From [email protected] on June 26, 2013 12:44:50 the temporally qualified inheres_in and bearer_of would be inverses if we did not have specific dependence.
If answer to both is that nothings is gained by specifically depends on either 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. |
From [email protected] on April 24, 2013 15:15:10
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: https://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: https://code.google.com/p/bfo/issues/detail?id=163
Original issue: http://code.google.com/p/bfo/issues/detail?id=165
The text was updated successfully, but these errors were encountered: