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

[oke464]

TL;DR

Open the file ReproduceErrorNumberFormatException2.ttl (files are in the attached .zip file).

Navigate to 'Entities'->'Classes'.

There are two trees: Navigating down tree 1 to subclass an error occurs. Navigating down tree 2 it works as expected. Check the error output (also included in attached file protege_error_output.txt).

Inspecting the file ReproduceErrorNumberFormatException2.ttl in a text editor the only difference is the data property "num value 92740100783". It works for other numbers, e.g. "92".

In details

Error info:

I have constructed a program that generates a turtle formatted file that I wish to open and use in protégé.

I have recreated a minimum example (file: ReproduceErrorNumberFormatException2.ttl) that mirrors the ontology structure I generate while still contains the error. With risk of a bold guess, it seems like protégé tries to parse the integer '92740100783' as a string, even though the range is set to xsd:integer. However, changing the number to another number, e.g. to '92', the parser works as expected.

Note the naming of the IRI:s where the SubClass contains the same IRI as its superclass followed by the '#' separator for the class name.

Could not find any related issues to NumberFormatException in the issues list.

To reproduce:

Inspect the file ReproduceErrorNumberFormatException2.ttl attached in the post. Notice the difference between: <http://www.semanticweb.org/ReproduceError/Testing/SuperClass1#subclass> and <http://www.semanticweb.org/ReproduceError/Testing/SuperClass2#subclass>. The only difference between 1 and 2 is the data property:

[ a owl:Restriction ;
    owl:hasValue 92740100783 ;
    owl:onProperty :num ]

Ideally start protege from a terminal session.

Open the file ReproduceErrorNumberFormatException2.ttl in protege.

Navigate to 'Entities'->'Classes'.

1. Open the class hierarchy in the following order to directly reproduce the error:

   owl:Thing>Head>Top1>SuperClass1>SubClass

Note that no data properties appears in this case. I expect all data properties in the class to show.
If you are running protege from a terminal session you can see the error message in the terminal output. Otherwise, try to save the ontology and the error should appear in a pop-up window.

This may cause protégé to bug a little, restart in that case and do the following:

2. Open instead the working hierarchy:

   owl:Thing>Head>Top2>SuperClass2>SubClass

Note that the data appears in this case, as expected.

Now, open the file ReproduceErrorNumberFormatException2.ttl in a text editor and change '92740100783' to '92' and open the file in protégé again, and follow the steps according to 1. above, and it should work as expected.

Error message

Uncaught Exception in thread 'AWT-EventQueue-0' 
java.lang.NumberFormatException: For input string: "92740100783"

See full error message in attached file protege_error_output.txt.

Version info

Linux: Pop!_OS 22.04 LTS (Ubuntu based)

Protégé: 5.6.1

Files

ReproduceError.zip

[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.