General and specific problems with ADO added object properties

[cstoeckert]

ADO has added several object properties which are problematic. OWLObjectProperty_00000000000000000000 isTreatmentFor is used as relation between the general class 'treatment' and 'Alzheimer's disease'. That means that any treatment is a treatment for AD which is not correct. This approach of applying the relation to general classes is used in other properties (isAnatomicalEntityFor, isCellularProcessFor, isDiagnosisFor, isSignAndSymptomFor, isModelFor, isEndPointFor) with similar issues.

OWLObjectProperty_00000000000000000002 isRiskFactorFor is applied to genes however the genes themselves are not a risk factor - it is specific variants that are risk factors.

OWLObjectProperty_00000000000000000004 isClassificationFor appears to be applied in a circular way: Alzheimer's disease isClassificationFor some Alzheimer's disease. Also how can a disposition be a classification?

[BideZ]

@cstoeckert Thank you for your feedback.

• OWLObjectProperty_00000000000000000000 I can understand that the term 'treatment' is defined as a collection for all types of disease.So would this issue be solved if I put the subclasses of 'treatment' as the domain of the object property instead of 'treatment' itself? An existing example would be isEndpointFor where the individual terms are used as domains in the usage of this object property.

• OWLObjectProperty_00000000000000000002 In this example you can see that all genes whose variation can lead to a higher possibility to a certain disease can be called risk factors, and I want to stick with this definition if it is fine.

• OWLObjectProperty_00000000000000000004 I would change the domain of this usage of object property to the specific subtypes. However, I am not sure if the circularity could be resolved.

Besides, we added/modified definitions of the object properties that we created, so they are less ambiguous. Please check the latest version

We are looking forward to your reply!

[cstoeckert]

@BideZ Thank you for trying to address these issues. I will just respond to one of the issues and try to address the others in future comments.

For OWLObjectProperty_00000000000000000004, you have given the textual definition: "The subject is categorized as a subtype of the object according to certain criteria such as topographic, anatomic, physiological, pathological, etiologic, epidemiological, statistical classifications." That is essentially a subclass which is already explicitly captured in your hierarchy.

[BideZ]

@cstoeckert Thank you for your feedback. We created these relations essentially as bin identifiers, so we could use these bins later for text mining. A similar example would be https://www.ebi.ac.uk/ols/ontologies/epio/properties?iri=https%3A%2F%2Fbio.scai.fraunhofer.de%2Fontology%2Fac113c60_c3d8_48f2_871c_cc34524d844f which was also created by our institute.

(We did not align these two object properties for reuse yet since we are still waiting for the feedbacks from RO)

[cstoeckert]

For OWLObjectProperty_00000000000000000002, you have given the textual definition: "The subject possesses characteristics whose variation can lead to an increased risk in resulting in a certain phenotype or condition (object)." That seems more appropriate but the label isRiskFactorFor should be improved to better match the definition. Perhaps something along the lines of 'variant is risk factor for'.

[BideZ]

@cstoeckert Thank you very much for your reply.

After reading it through again, I think the definition might be inappropriate for some usages other than genetic risk factors such as homocysteine, diabetes and obesity. Therefore I would change the definition of 'isRiskFactorFor' to 'The subject possesses characteristics leading to an increased risk in developing a certain phenotype or condition (object). The example of risk factors could be age, family history, consumption of certain products, being exposed to chemicals or radiations, having certain underlying conditions or being infected by an microorganism'

And in parallel I would add another object property 'VariantisGeneticRiskFactorFor' which includes the risk factor genes responsible for developing AD. I would put the definition for 'VariantisGeneticRiskFactorFor' in this way: The subject gene has variation that can lead to an increased disease risk, but does not directly cause a disease.'

I am looking foraward to your reply :)

[cstoeckert]

@BideZ my main concern about risk factor was stating that it applied to genes as opposed to genetic changes so your proposal to use a different property including variants should address that. As you have done with your other object properties, it should be submitted to RO.

[cstoeckert]

Regarding the general issue of applying object properties about treatment, end points, etc. at too high of a hierarchy level, yes making the subject of the property specific for the object would address that. However, in the example above for 'isEndpointFor' there is a problem that highlights just being more specific is not enough. End points are typically the final stage of a process but your definition of "The subject is a cause or result in the pathogenesis of a condition (object)." doesn't match that. Even if the label is ignored, the definition doesn't fit having subjects like 'cognitive measurement' or 'Mini-Mental State Exam Score'. Those data items may be indicators of Alzheimer's disease but it is not accurate to say they are causes or results. Even amyloid-beta and MAPT are problematic as they are not in themselves causes or results or endpoints but are components of things (plaques and tangles) that are.

[BideZ]

@cstoeckert During this push, we changed the usages of 'is Risk Factor For' and created 'VariantisGeneticRiskFactorFor' as discussed. Besides, we changed the label and redefined the 'Endpoint' property. We deleted some inappropriate usages and added some ones that are more suitable in the context.

[cstoeckert]

@BideZ Thank you for your responses to address the issues raised. The changes made do look more suitable. There are still problematic usages (e.g., 'Alzheimer's disease' SubClassOf OWLObjectProperty_00000000000000000004 some 'Alzheimer's disease') that I hope you will also address.

[BideZ]

@cstoeckert Thank you for your reply. I shifted the subtypes under 'dementia', so circularity could be resolved. Besides, I relabelled the object property as 'is Classified Subtype For'. I understand that this object property could be similar to 'SubclassOf', but we do need object properties for the bins (I also mentioned this in the RO issue) with which we can perform text mining and filter out data.

Please let me know if there are any other questions regarding the object properties. :)

[BideZ]

@cstoeckert Currently we are waiting for all the possible feedbacks about the object properties from you, so that we could submit the newly defined/redefined axioms to the RO. Therefore, it would be nice if we could discuss all the possible issues regarding object properties prior to specific classes, considering RO review is a rather lengthy process. It would also be nice if you could mention it in the comment if everthing regarding ADO object properties is clear. Thank you very much!

[cstoeckert]

@BideZ Here are some additional concerns / recommendations for you to consider regarding the object properties. Please keep in mind that these reflect my views and that editors of RO may have other/ different issues. isClassifiedSubtypeFor: Sorry but I still think that this property doesn't make sense as you have defined and applied it. It sounds like what you want to do is associate text (i.e., information content entity)about a subtype of something with a higher level type which would be OK. If so, you should make the domain of this property an 'information content entity' or even a 'textual entity' and consider making it a subproperty of 'is about' with a label like 'is about a subtype of'. If that works for you, you would need to create classes about the subtypes (e.g., 'text about Alzeimer's Disease 16') and use them as subjects rather than the subtypes themselves. This would actually help you a lot in that you can make these classes more useful for tagging; my understanding is that the AD literature rarely refers to numbered types of AD. It would help clarify the rest of your proposed properties if you could include domains and ranges keeping in mind making the distinction between information about a thing and the thing itself. On a side note, I noticed when looking at the isClassifiedSubtype property that users will find your hierarchy of Alzheimer's Disease strange. Alzheimer's Disease is off by itself under tauopathy and not connected (except by your problematic property) to the subtypes of Alzheimer's Disease. They would be if you imported the full hierarchy from DO or MONDO. I can take another look at the other properties but will wait for your response about these points first. Thanks.

[BideZ]

@cstoeckert Thank you very much for the reply. Sorry for the late reponse.

• I think there is a confusion here due to how we have defined the object property, especially the last half part of the definition.

isClassifiedSubtypeFor: 'The subject is categorized as a subtype of the object according to certain criteria such as topographic, anatomic, physiological, pathological, etiologic, epidemiological, statistical classifications.' By doing so, we were trying to make a clearer difference between this object property and 'isSubclassOf', so it could be reused later on for a specified purpose and avoid circular usage. We did not intend to connect the information such as the classification criteria of AD subtypes with its higher level type.

To resolve this confusion, we would only include the first half of the definition that we provided, as in isClassifiedSubtypeFor: 'The subject is categorized as a subtype of the object.

-We relocated the suptypes back to the parent class 'Alzheimer's Disease' which now is under both taupothy and dementia. Thank you!