-
Notifications
You must be signed in to change notification settings - Fork 47
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
should contained_in be a sub-property of located_in? #693
Comments
Whereas, the range for So, it seems that I do not understand why |
Ah, I somehow hadn't noticed the domain & range for I understand that it might not be acceptable for My original question was rooted in my understanding based on the textual definitions of the two properties. Paraphrasing:
|
Yes. It is redundant. I don't know why it is there.
Nice catch! I didn't notice that. This raises the question (to me at least) as to why
Yes. The domain of However the range of
Sorry ... not following you here. A
Linguistically, this seems to be the case. Perhaps this is good reason for Can others more familiar with the history of the |
This comes from the bfo reference guide. I do not think SR is a useful
class and I do not think we should have unusual complex expressions as
ranges or domains
The solution here is a simple range plus an additional complementof axiom
to exclude SR
…On Fri, Mar 10, 2023 at 5:46 AM Bill Duncan ***@***.***> wrote:
The range for contained in is
[image: image]
<https://user-images.githubusercontent.com/3186638/224330142-8772bf99-ff54-48b0-8432-1d151d7abe7c.png>
Whereas, the range for located in is
[image: image]
<https://user-images.githubusercontent.com/3186638/224330015-9d5fe53d-f7d9-4c42-8ec6-c014e4a52943.png>
So, it seems that located in should be a subproperty of contained in.
I do not understand why located in excludes spatial regions in its range.
Perhaps located in is meant to be reserved for cased where a material
entity bounds the spatial region (in some sense). I'm only speculating
here. Maybe one of the RO gurus (e.g., @cmungall
<https://github.com/cmungall> @balhoff <https://github.com/balhoff>
@dosumis <https://github.com/dosumis> ) can shed more light on this.
—
Reply to this email directly, view it on GitHub
<#693 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMMOJZB3VSEQEMWMX7RFDW3MWCZANCNFSM6AAAAAAVVYRBE4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I should have been more clear in my original issue-description, I think. As noted, it seems from the textual description of
|
Thanks @wdduncan, happy to! I should be able to join for the first 30 minutes; not sure how long those meetings usually go. I'll look at the minutes doc tonight or tomorrow. UPDATE: I glanced at the minutes-doc; I've nothing to add past what's there and what's already in this thread (particularly my March 12 explanation. Looks likely that this issue will come up sometime after the first 30 min, but I'll plan to Zoom in to the mtg, just in case. Looking forward. |
Unfortunately, I won't be able to attend the mtg today. |
@jclerman The next meeting is on 2023-04-25 (9am PT, 12pm ET, 6pm CET). |
There are some questions in the agenda for the next ro meeting, I will copy them here and answer here, to keep things in one place:
See the editor note for this property: "Containment obtains in each case between material and immaterial continuants, for instance: lung contained_in thoracic cavity; bladder contained_in pelvic cavity. Hence containment is not a transitive relation." However, confusingly, the range of this relation in RO is less restrictive, as is IC.
Yes, it would. But as I noted above, the range of located_in comes from BFO, and the BFO reference guide states Also in BFO 2020 the range of the temporalized form of located_in in 'independent continuant' PROPOSAL We should simply obsolete contained_in
We should leave located_in as-is. |
Thanks @cmungall I didn't catch that!
Yes. I was well aware of that. I just don't understand the reasoning behind it :( I agree with your proposals:
|
Should be merged before oborel/obo-relations#739 For full discussion, see oborel/obo-relations#693
* Obsoleting contains and contained in. Fixes #693 * adding seeAlso to issue --------- Co-authored-by: Anita Caron <anitac@ebi.ac.uk>
I didn't see this question mentioned in earlier issues, nor do I see it addressed in the descriptions of the respective properties, so:
As best I can tell,
contained_in
(RO:0001018) is a special case oflocated_in
(RO:0001025) - would it make sense to acknowledge that by making the former a sub-property of the latter?I'm trying to decide how best to use these in an ontology I'm developing, and insight on this question would be helpful.
The text was updated successfully, but these errors were encountered: