Skip to content
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

Closed
jclerman opened this issue Mar 10, 2023 · 11 comments · Fixed by #739
Closed

should contained_in be a sub-property of located_in? #693

jclerman opened this issue Mar 10, 2023 · 11 comments · Fixed by #739
Labels
obsolete This includes both obsolete and merge requests question

Comments

@jclerman
Copy link

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 of located_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.

@jclerman jclerman changed the title should contained_in be a sub-property of located_in should contained_in be a sub-property of located_in? Mar 10, 2023
@wdduncan
Copy link
Collaborator

The range for contained in is
image

Whereas, the range for located in is
image

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 @balhoff @dosumis ) can shed more light on this.

@jclerman
Copy link
Author

jclerman commented Mar 11, 2023

Ah, I somehow hadn't noticed the domain & range for located in. Something's a bit odd about it (but maybe that's in deference to the reasoners in common use) since technically, the 2nd element of the range-intersection (independent continuant) is redundant.

I understand that it might not be acceptable for located in to be a subproperty of contained in, since located in is marked as transitive, but contained in is not. Also, perhaps more to the point, the textual definition of the range of contained in seems narrower than the one for located in.

My original question was rooted in my understanding based on the textual definitions of the two properties. Paraphrasing:

  • contained in is a relationship between material and immaterial continuants (this is already in conflict with the asserted OWL range independent continuant - so it'd be nice to get those into alignment if possible). Examples include physical things that are related to immaterial spaces ("lung in thoracic cavity", etc) and so this is stipulated not to be a transitive relation (though with correct domain & range criteria, that stipulation should be unnecessary, I think).
  • located in appears, based on textual description, to be broader than contained in - it's just any two independent continuants, one of which is entirely "within" the other. That seems (to me) to be true of any contained in relation - thus my suggestion.

@wdduncan
Copy link
Collaborator

the 2nd element of the range-intersection (independent continuant) is redundant.

Yes. It is redundant. I don't know why it is there.

it might not be acceptable for located in to be a subproperty of contained in, since located in is marked as transitive, but contained in is not

Nice catch! I didn't notice that. This raises the question (to me at least) as to why contained in isn't defined as transitive. Seems to make sense that if X contained in Y and Y contained in Z, then X contained in Z. However, the reason for creating the relation may involve a use case for which transitivity doesn't apply. I don't know the history of the relation.

contained in is a relationship between material and immaterial continuants

Yes. The domain of contained in is more restrictive (material entity) than the domain of located in, which incudes immaterial entity (such as site) sans spatial region.

However the range of contained in is less restrictive than the range located in

(this is already in conflict with the asserted OWL range independent continuant ...)

Sorry ... not following you here. A spatial region is a type of immaterial entity (i.e., a type of immaterial continuant).

located in appears, based on textual description, to be broader than contained in ...

Linguistically, this seems to be the case. Perhaps this is good reason for contained in to be a subproperty of located in.

Can others more familiar with the history of the contained in relation weigh in?

@cmungall
Copy link
Contributor

cmungall commented Mar 11, 2023 via email

@jclerman
Copy link
Author

I should have been more clear in my original issue-description, I think.

As noted, it seems from the textual description of located in and contained in that the former is broader than the latter, and that it would therefore be convenient for contained in to be modeled as a sub-property of located in. But that's based on an implicit assumption on my part, which may be incorrect. To wit:

located in

The definition annotation for located in is:

a relation between two independent continuants, the target and the location, in which the target is entirely within the location

So, it sounds like the OWL range & domain should both be independent continuant. spatial region is excluded in the current OWL range & domain - but I don't see an explanation for that in the above definition, nor is it obvious what modeling benefit that exclusion confers.

contained in

The definition annotation for contained in begins:

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.

To me, it sounds like that should translate to an OWL domain & range of material entity and immaterial entity, respectively. The currently modeled range for contained in is independent continuant, which is too broad given the textual description (that's what I meant above, when I said the OWL range was "in conflict" with the textual definition).

So, that's what led to my original question. If the OWL range and domain of the two properties were to be updated to what it sounds like their textual descriptions describe, located in could at least possibly be a super-property of contained in, and that would make for a slightly simpler more elegant model (IMO) - since it does seem natural that things that are "contained" in something are also "located" in it (though not necessarily vice-versa).

@wdduncan
Copy link
Collaborator

@jclerman There is RO call on Tues. 03/28 at 12pm ET. Zoom link

Are you able to join?

See here for the meeting minutes if you want to comment on your issue.

@jclerman
Copy link
Author

jclerman commented Mar 27, 2023

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.

@jclerman
Copy link
Author

Unfortunately, I won't be able to attend the mtg today.

@wdduncan
Copy link
Collaborator

@jclerman The next meeting is on 2023-04-25 (9am PT, 12pm ET, 6pm CET).

@cmungall
Copy link
Contributor

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:

Why is contained in not transitive? Is there a history to this we need to be aware of?

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.

In order to make this work, the range of located in would need to be changed (I think).
The range of contained in is independent continuant.
The range of located in is independent continuant and not spatial region.
I.e., the range of located in is more restrictive than contained in.

Yes, it would. But as I noted above, the range of located_in comes from BFO, and the BFO reference guide states

image

Also in BFO 2020 the range of the temporalized form of located_in in 'independent continuant'
and (not ('spatial region'))

PROPOSAL

We should simply obsolete contained_in

  1. it appears to be unused and all use cases are satisfied by located_in
  2. contained_in was introduced to be consistent with the 2005 RO paper, but contained was removed in BFO. The BFO2 reference guide states: "Revision of treatment of spatial location: We generalize the treatment of located_in and remove the relation contained_in."
  3. the existence of both of these causes confusion

We should leave located_in as-is.

@wdduncan
Copy link
Collaborator

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

Thanks @cmungall I didn't catch that!

the range of located_in comes from BFO, and the BFO reference guide

Yes. I was well aware of that. I just don't understand the reasoning behind it :(

I agree with your proposals:

  • obsolete contained in
  • leave located in as is

cmungall added a commit that referenced this issue Jul 18, 2023
cmungall added a commit to EnvironmentOntology/envo that referenced this issue Jul 28, 2023
@nlharris nlharris added question obsolete This includes both obsolete and merge requests labels Aug 14, 2023
anitacaron pushed a commit that referenced this issue Aug 16, 2023
* Obsoleting contains and contained in.

Fixes #693

* adding seeAlso to issue

---------

Co-authored-by: Anita Caron <anitac@ebi.ac.uk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
obsolete This includes both obsolete and merge requests question
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants