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

Replace site->immaterial entity in spreadsheet #11

Closed
cmungall opened this issue Feb 8, 2019 · 13 comments
Closed

Replace site->immaterial entity in spreadsheet #11

cmungall opened this issue Feb 8, 2019 · 13 comments

Comments

@cmungall
Copy link
Contributor

cmungall commented Feb 8, 2019

Rationale:

  • principle of least commitment
  • the term 'site' is terribly overloaded we want to avoid clashes with names chosen by domain scientists to mean something different
  • the only reason to use site is if we feel we need to distinguish from non-site IMs, but these are bfo regions, which I am not sure there is a use case for except newtonian physics ontologies
@alanruttenberg
Copy link
Member

Spatial regions can't be part of material entities, but sites can.

@cmungall
Copy link
Contributor Author

when would anyone in our domain (or any domain) ever need to use SRs?

@alanruttenberg
Copy link
Member

I'm not sure how that is relevant? If no one uses SR then we don't include the term SR.

I'm going on the principle that if we mean site, then we should say site. If the label isn't good, then we can add an alternative label. Or lobby for a change in BFO's label.

Whether it matters, and to what extent, depends on usage.

Immaterial entities include boundaries as well, BTW

@cmungall
Copy link
Contributor Author

@dosumis any preferences? I personally prefer least commitment. Because I don't understand SRs I don't know for sure whether some of the IEs we use may later turn out to be SRs, which would break things if we overcommit. Also, BFO is not closed. Maybe there will be other kinds of IEs which are neither SR or sites, and our entities may turn out to be in a mix.

If we do commit to site then really we should do this across the board, and we should rename all terms like 'immaterial anatomical entity' to 'anatomical site' and deepen the existing subClassOf axioms.

@bpeters42
Copy link
Contributor

bpeters42 commented Feb 13, 2019 via email

@cmungall
Copy link
Contributor Author

I just remembered boundary is under IM. This is a useful concept. So ignoring ugly labels or over/under commitment, we would either need to bring in IM as a grouping, or implement this pattern BFO-ontology/BFO#221 to get power of owl reasoning

@bpeters42
Copy link
Contributor

bpeters42 commented Feb 13, 2019 via email

@dosumis
Copy link

dosumis commented Feb 13, 2019

I prefer to keep it to 'sites'. 'immaterial entity' as a label sucks, as most people would assume that to include roles, functions, information content and the like.

I'm not aware of that confusion. Isn't it only ontologists who think of functions roles and information content as entities? Maybe it depends on context? I think it's highly unlikely that anyone seeing the term 'immaterial entity' in an anatomy ontology would assume it refers to any of these things.

'Site' feels like a slightly odd term - in my mind it immediately begs the question - what's special about a space/immaterial entity that makes it a site? It's also loaded, e.g. in the context of proteins, people are likely to think of active-sites. In the context of anatomy at least, if we want something more specific than 'immaterial entity' then I'd go for 'cavity'.

Question - how deep will OBO-core be? are we going for a single layer of intermediate terms between BFO and everything else, or will it have some nested structure. e.g. if cavity is too specific (implies material boundary which may not the case with site?), then could OBO-core have

site
. cavity ?

@alanruttenberg
Copy link
Member

@dosumis What makes site different from spatial region is that a site is anchored to a material entity. Consider two people with infections, walking towards each other. You can take the people's position as relative to a spatial region, but then the sites of the infections occupy different spatial regions at different times.

If boundaries and sites are both needed, and SR not, then I suggest leaving sites and adding boundaries. If someone can think of a unifying parent, then add that too - it doesn't need to be in BFO since it's completely defined by the union of the two classes.

@bpeters42
Copy link
Contributor

bpeters42 commented Feb 13, 2019 via email

@dosumis
Copy link

dosumis commented Feb 13, 2019

@dosumis What makes site different from spatial region is that a site is anchored to a material entity.

I get that this is (was?) the intent of the BFO term, but I thought with OBO core we were looking for intermediate level terms with intuitive names. If that is the case, perhaps we're still too far up in abstraction here, and we should instead be looking for more specific terms to expose in OBO-core. I suspect that cavity could cover all sites we need to refer to in anatomy, and would also be useful for other domains. If I understand correctly, a site is broader than a cavity - for example covering the portion of atmosphere above Greater London. Maybe we should retain site in OBO core for that purpose, preferring cavity in all other cases?

@cmungall
Copy link
Contributor Author

Alternate proposal: obo-core only brings in IC (perhaps giving it a nicer name, but we shouldn't use the extent of ugliness of the BFO name dictate the modeling)

Caring about subdivisions of the IC becomes the business of domain ontologies.

Note we'll still have D+R axioms that are more specific, but this will be true unless we include 85% of BFO. I think we just get around this with the BFON pattern.

@cmungall
Copy link
Contributor Author

cmungall commented Aug 8, 2019

I think this can be closed now since we aren't using the spreadsheet anymore?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants