Upgrade to OWLAPI 4.5.24 made CTO unqueriable

[psiotwo]

Querying the ontology:

<?xml version="1.0"?>
<Ontology xmlns="http://www.w3.org/2002/07/owl#"
     xml:base="http://purl.obolibrary.org/obo/cto.owl"
     ontologyIRI="http://purl.obolibrary.org/obo/cto.owl">
    <Prefix name="" IRI="http://purl.obolibrary.org/obo/cto.owl"/>
    <Prefix name="rdf" IRI="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>
    <Prefix name="rdfs" IRI="http://www.w3.org/2000/01/rdf-schema#"/>
    <AnnotationAssertion>
        <AnnotationProperty abbreviatedIRI="rdfs:label"/>
        <AbbreviatedIRI>obo:CTO_0000073</AbbreviatedIRI>
        <Literal datatypeIRI="http://www.w3.org/1999/02/22-rdf-syntax-ns#langString">primary registry</Literal>
    </AnnotationAssertion>
</Ontology>

with the current version of ROBOT ends up with

java.lang.IllegalArgumentException: datatype rdf:langString requires a language tag

Seems to be related to the upgrade of OWLAPI 4.5.24 (4efec37) and the respective RDF4J upgrade.

This makes e.g. CTO unqueriable.

[matentzn]

Thanks for the report @psiotwo - I am expecting a few of these now for a while.

The previous parsers where a bit more permissive than the new one - this is not a ROBOT issue, this is an OWL API issue.

If you think CTO is using valid OWLXML, and the OWL API fails to parse it, we need to make an OWL API bug report. You can tag me in it, and I will see that we can find some resources to fix it.

[psiotwo]

I reported here because it is a regression w.r.t. last ROBOT release.

Seems to me it belongs to a gray zone of OWL/XML, OWL syntax specs (unless I missed some bit), but does not seem to make sense having langStrings without language tags (ClinicalTrialOntology/CTO#40).

Yes, it can be relaxed on RioUtils.tripleAsStatements inside OWLAPI, but would be quite a hack.

[matentzn]

What is your suggested course of action here wrt ROBOT?

[psiotwo]

If I came across this issue around 60d46f6, then I would suggest adding a new option 'strict/relaxed' preventing OWLAPI to die inside the QueryOperation processing.

But since the handling logic was moved to RioUtils, which might have a much broader scope/usage?!?, I am no more sure at this point, as I still see the problem mostly on the side of data.

So I would think,

1. keep just things recorded for others not be surprised when they come across the same problem and
2. propagate the problem to the curators of the affected ontologies.

[matentzn]

I think I agree with you @psiotwo!