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

Document: Under no circumstances use the "reflexive", "irreflexive" characteristics in RO #747

Open
matentzn opened this issue Aug 16, 2023 · 4 comments

Comments

@matentzn
Copy link
Contributor

Reflexive and irreflexive do not mean what you think they mean - they create global inferences (as opposed to local ones, like transitivity). For example, just saying "Reflexive(R)", causes all entities in the domain (classes! individuals!) to be connected with itself via R. In the sense of: Reflexive(LovesThemselves) implies that everything, including the specifically dependent continuants which are known to be nasty and loveless, love themselves.

Some related discussions in here: #151

@matentzn
Copy link
Contributor Author

It is already documented?

@wdduncan wdduncan reopened this Aug 16, 2023
@wdduncan
Copy link
Collaborator

@matentzn Sorry. I thought the PR addressed this (which is why I closed it). I don't know about the documentation. So, I reopened it.

@cmungall
Copy link
Contributor

We definitely caution against it, but we could be more forceful:
https://oborel.github.io/obo-relations/reflexivity/

Note we have many relations declared Irreflexive:

ro terms --owl-type owl:IrreflexiveProperty
RO:0002351 ! has member
RO:0002551 ! has skeleton
RO:0003301 ! has role in modeling
RO:0009001 ! has substance added
RO:0009002 ! has substance removed
RO:0009003 ! immersed in
RO:0009005 ! has primary substance added
RO:0017004 ! negatively correlated with

I don't think we're suggesting to remove this? If anything the list could be expanded. This in theory buys us more QC checking, in practice I am not sure of the value

Will this ticket be closed by a PR to the end-user documentation (justification of why we don't have this) or editor's documentation/sparql checks?

@matentzn
Copy link
Contributor Author

Editors docs should clearly say, at least, not to use reflexive characteristic and describe under which circumstances irreflexive is ok (hard to imaging any, as irreflexive really does not mean much on class level).

Maybe we should just add a qc check to forbid reflexive characteristic

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

3 participants