EquivalentClasses with DataHasValue

[rwynne]

Attached is a simple Java class along with two small ontologies (rename extensions as needed). Each ontology has two classes that are "clones" with differing IRIs (fragments 392656009 and Copy-392656009).

Reasoning the file with DataHasValue axioms, the two classes are not returned as equivalent.
Reasoning the file without DataHasValue axioms, the two classes are equivalent.

For my use case, I have been creating RxNorm classes within the SNOMED ontology and then report areas where clinical drugs do not align. As you can imagine, it is still extremely valuable to get these class equivalencies for free. Now that these value axioms have moved away from using numbers represented as classes, is this still possible?

Note: If I view both ontologies in Protege (version 5.5.0-beta-7) and run ELK, the equivalence sign is visible in the hierarchy!

TestELK.txt
with-datahasvalue.txt
without-datahasvalue.txt

[ykazakov]

Thanks for the detailed report! Which version of ELK did you use?
In general ELK is not guaranteed to derive equivalences of identical classes that contain unsupported features (and DataHasValue is not fully supported). However, version 0.4.3 indeed derived equivalences for DataHasValue because they were represented by identical internal objects. Any reason why you cannot use this version from OWL API?

In the latest development version 0.5.0-SNAPSHOT this behaviour has changed due to changes in the internal representation, so identical classes in your example are not detected as equivalent. I can take a look if the old behaviour can be restored.

I would appreciate if you could use small examples in your report. Most of the content of the attached files are not relevant for the issue.

[rwynne]

Which version of ELK did you use?

0.5.0-SNAPSHOT

Any reason why you cannot use this version from OWL API?

I can certainly try it. There was a reason for upgrade. I think it was to upgrade to owlapi 5. Do you recall which version of the owlapi should be used with 0.4.3?

Now that you mention it, the 0.4.3 plugin must be the reason Protege displays the equivalency sign. 💡

I can take a look if the old behaviour can be restored.

This would really help solve my use case! 👍

I would appreciate if you could use small examples in your report. Most of the content of the attached files are not relevant for the issue.

Apologies the small inputs are thorough. The content not relevant (at least to us developers) is necessary to draw a Protege view for my superiors who are more interested in seeing names rather than codes in class definitions. I can keep these concise for you going forward. ✔️

[rwynne]

@ykazakov Any updates if this behavior can be restored?

In the case of SNOMED, I wrote a workaround to back-convert the concrete domain values to owl classes and add their former object properties. This was simpler than downgrading to OA4 and 0.4.3.

[ykazakov]

@rwynne sorry, I did not have much time to work on ELK yet.

[rwynne]

@ykazakov Any updates to this issue? A fix may also benefit Protege issue protegeproject/protege#910 . Thanks!

[balhoff]

Hi @ykazakov I found this issue as I just came to report this behavior change as well. In my case I was relying on ELK 0.4.3 finding A and B equivalent in this ontology:

Ontology(
Declaration(Class(<http://example.org/A>))
Declaration(Class(<http://example.org/B>))
Declaration(Class(<http://example.org/C>))
Declaration(ObjectProperty(<http://example.org/r>))
EquivalentClasses(<http://example.org/A> ObjectComplementOf(ObjectSomeValuesFrom(<http://example.org/r> <http://example.org/C>)))
EquivalentClasses(<http://example.org/B> ObjectComplementOf(ObjectSomeValuesFrom(<http://example.org/r> <http://example.org/C>)))
)

These structural equivalences can be very useful in coercing ELK to materialize certain unsupported inferences.

[matentzn]

I also need to chip in on this issue - it would be very very good if we could get this done, as I am now under pressure by my PIs to devise workarounds to simulate the old 0.4.3 behaviour, which ends up in a lot of spaghetti code.