Specific value of data property with range xsd:integer in nested class tree raises NumberFormatException about protege

[gouttegd]

I believe this is a limitation of the OWL API. It uses java.lang.Integer to represent integer values, so the biggest integer it can accept is 2 147 483 647 (2³¹ − 1) – any bigger value would trigger the bug.

[oke464]

I believe this is a limitation of the OWL API. It uses java.lang.Integer to represent integer values, so the biggest integer it can accept is 2 147 483 647 (2³¹ − 1) – any bigger value would trigger the bug.

Thank you for quick response! Ah, yes this is a good point. I do not know how OWL API handles this in the background, but I have also tried with the xsd:long type, but that did not help.

However, in the following example (ReproduceErrorNumberFormatException3.zip), the same number works with the xsd:integer type. The difference between the examples ReproduceErrorNumberFormatException2.zip and ReproduceErrorNumberFormatException3.zip are the nested classes.

Also, there is another case in our ontology where a larger number, 149597870700, is used; this works in the nested classes when the other data properties are removed. See example ReproduceErrorNumberFormatException4.zip.

In the case that the OWL API integer fix does not work, maybe these examples can give more clues?

[gouttegd]

Very interesting. It seems the issue is more subtle than I thought.

Contrary to what I thought, the OWL API is in fact capable of dealing with arbitrary large integer values. When an integer value is too large to fit into a 32-bit integer, the OWL API stores it as a plain string, which can be as large as needed.

As long as that value is not compared to any other integer value, it all works fine. So a class expression like this num value 92740100783 (as in your example 3), on its own, causes no problem.

But a class expression like this SuperClass1 and (exp value -34) and (num value 149597870700) (as in your example 4) does cause an issue, because at some point the different operands of the intersection need to be compared between each other. And it seems the code in the OWL API that performs that comparison cannot handle properly the case when one of the integer it has to compare is a large integer stored as a string (it just tries to parse the string into an integer, resulting in a NumberFormatException because the value is too large).

I’m afraid there’s nothing that can be done in Protégé – it’s purely an OWL API issue. I’ll open a ticket there.