Cyclic imports and missing declarations cause parsing error #798
Labels
Comments
|
Do you have an example to share? There are recent bug fixes in the area which have not been released yet. |
|
ImportsHasAnnotationAxiom.txt Github wouldn't let me upload When I try to process |
|
bao_core.owl.txt This issue is still happening with the circular dependency between |
|
I am using 5.1.9 |
|
@ignazio1977 Can I use this issue still or should I create a new issue? |
|
This one is fine |
|
Has there been any updates on this? Have you been able to replicate the issue with the provided ontologies? |
|
I've tried to replicate this but failed again. I've added some debug calls and, at the point where the stack trace above, the ontologies being compared have the same annotation axioms: Would you mind running the code above in your setup, just to confirm there is only one OWLAPI version in your path? |
|
Looking at the stack trace line numbers, I believe your first error came from OWLAPI 5.1.7. I've tried running my code with that version, but still cannot replicate the problem. At the bottom of the stack trace, the classes involved appear to use a Sesame model as source for the ontology. Maybe the translation causes the order in which triples are seen to be different, and that's what's triggering the exception. Can you share that code? |
|
The first error was from OWLAPI 5.1.7. The newer error with BAO is definitely 5.1.9. It looks like the error stems from the VersionIRI matching the OntologyIRI in bao_complete.owl. |
It seems like there are 4 axioms different when comparing ontologies? |
|
Sorry if I didn't communicate this well before. The issue is with I believe that |
Thanks, that finally allowed me to replicate the failure. I'm also seeing another issue - I get random errors stating the XML is not well formed, always at different lines. This disappears if I open the connection, read all content into a local buffer and then parse from the buffer, making me wonder if the issue is related to timeouts happening while the parsing is ongoing. |
|
Switching on logging at the error level, turns out there are four axioms that cannot be parsed properly on the first pass, this causes them to be parsed with My guess at this point is that there are properties declared in the import closure but the circular dependency gets in the way of proper resolution. |
|
It is difficult to design a general solution: with non cyclic imports, it is sufficient to parse the imported ontologies before the current ontology, recursively, to guarantee that all relevant declarations have been seen. But with a cyclic import, it is necessary to parse all ontologies to make sure all entity declarations have been seen, before all axioms can be successfully parsed. The current strategy fails because the declarations are in the ontologies standing between the two occurrences of It's a pretty big refactor of all the parsers to allow axiom parsing to be delayed until all ontologies have been parsed, so I'm not sure how long it is going to take to address. In the meantime, a workaround would be to add the missing declarations to the ontology - duplicate declarations in the import closure do not cause errors, not until there are changes to be made, anyway. Another workaround would be to remove the cycle - is it correct for |
|
Unfortunately I do not manage |
ignazio1977
changed the title
ignazio1977
added a commit
that referenced
this issue
Mar 3, 2019
Ontology A imports ontology B, ontology B imports ontoloy A and ontology C, ontology C provides declaration for property P, ontology A uses property P. When loading A through its IRI, an ontology rename failure exception is raised. the reason is that A is parsed twice, once before and once after ontology C is parsed. However, when ontology C has yet to be parsed, there is no declaration available for P. This means that P is assumed to be an annotation property (only possible assumption, as the alternative is to throw a parsing error), and when the parsing of A completes, its id needs to be set with the value read from the ontology. However, at this point the two ontologies have the same id but not the same content - P has one guessed type and one parsed type, and the corresponding axioms differ. Hence, the api interprets this as two diffrent ontologies with the same id - which cannot coexist in the same manager. The full solution for this is for the parsers to work on two levels: ontology imports closure and entity declarations parsing, and axiom parsing. The ontologies to import and the declarations in each ontology would be parsed first, and once the closure has been computed, each ontology can be parsed with full knowledge of the entities declared - this removes the source of the error, in that there won't be any more cases of entities being used when their declaration has not been processed yet due to imports resolution and cycles. (This is how parsing is outlined in the specs, but it's not working exactly this way in practice and it's a considerable refactor for the current parsers.) (Other root issue: cycles in imports, this is not an indicator of a healthy ontology structure. It's allowed in OWL 2, but I cannot think of a scenario where the ontolgies wouldn't be easier to work with with imports refactored to not be cyclic). Luckily, when loading by IRIs, it's easy to avoid double parsing by adding the root ontology used at load time to the map of ontologies being imported, which is currently used to skip ultiple imports in the imports closure. The root was not included in this mechanism, for some reason - it should have been. Removing double parsing removes both issues, however the problem remains for root ontologies loaded from file or stream.
ignazio1977
added a commit
that referenced
this issue
Mar 3, 2019
Ontology A imports ontology B, ontology B imports ontoloy A and ontology C, ontology C provides declaration for property P, ontology A uses property P. When loading A through its IRI, an ontology rename failure exception is raised. the reason is that A is parsed twice, once before and once after ontology C is parsed. However, when ontology C has yet to be parsed, there is no declaration available for P. This means that P is assumed to be an annotation property (only possible assumption, as the alternative is to throw a parsing error), and when the parsing of A completes, its id needs to be set with the value read from the ontology. However, at this point the two ontologies have the same id but not the same content - P has one guessed type and one parsed type, and the corresponding axioms differ. Hence, the api interprets this as two diffrent ontologies with the same id - which cannot coexist in the same manager. The full solution for this is for the parsers to work on two levels: ontology imports closure and entity declarations parsing, and axiom parsing. The ontologies to import and the declarations in each ontology would be parsed first, and once the closure has been computed, each ontology can be parsed with full knowledge of the entities declared - this removes the source of the error, in that there won't be any more cases of entities being used when their declaration has not been processed yet due to imports resolution and cycles. (This is how parsing is outlined in the specs, but it's not working exactly this way in practice and it's a considerable refactor for the current parsers.) (Other root issue: cycles in imports, this is not an indicator of a healthy ontology structure. It's allowed in OWL 2, but I cannot think of a scenario where the ontolgies wouldn't be easier to work with with imports refactored to not be cyclic). Luckily, when loading by IRIs, it's easy to avoid double parsing by adding the root ontology used at load time to the map of ontologies being imported, which is currently used to skip ultiple imports in the imports closure. The root was not included in this mechanism, for some reason - it should have been. Removing double parsing removes both issues, however the problem remains for root ontologies loaded from file or stream.
ignazio1977
added a commit
that referenced
this issue
Mar 4, 2019
Ontology A imports ontology B, ontology B imports ontoloy A and ontology C, ontology C provides declaration for property P, ontology A uses property P. When loading A through its IRI, an ontology rename failure exception is raised. the reason is that A is parsed twice, once before and once after ontology C is parsed. However, when ontology C has yet to be parsed, there is no declaration available for P. This means that P is assumed to be an annotation property (only possible assumption, as the alternative is to throw a parsing error), and when the parsing of A completes, its id needs to be set with the value read from the ontology. However, at this point the two ontologies have the same id but not the same content - P has one guessed type and one parsed type, and the corresponding axioms differ. Hence, the api interprets this as two diffrent ontologies with the same id - which cannot coexist in the same manager. The full solution for this is for the parsers to work on two levels: ontology imports closure and entity declarations parsing, and axiom parsing. The ontologies to import and the declarations in each ontology would be parsed first, and once the closure has been computed, each ontology can be parsed with full knowledge of the entities declared - this removes the source of the error, in that there won't be any more cases of entities being used when their declaration has not been processed yet due to imports resolution and cycles. (This is how parsing is outlined in the specs, but it's not working exactly this way in practice and it's a considerable refactor for the current parsers.) (Other root issue: cycles in imports, this is not an indicator of a healthy ontology structure. It's allowed in OWL 2, but I cannot think of a scenario where the ontolgies wouldn't be easier to work with with imports refactored to not be cyclic). Luckily, when loading by IRIs, it's easy to avoid double parsing by adding the root ontology used at load time to the map of ontologies being imported, which is currently used to skip ultiple imports in the imports closure. The root was not included in this mechanism, for some reason - it should have been. Removing double parsing removes both issues, however the problem remains for root ontologies loaded from file or stream.
If your tool works via the |
|
This fix is in release 5.1.10, which should now be on maven central. |
|
We actually use the RioParser to parse a sesame model where this is breaking so I don't believe this fix will help us just yet :( |
|
Uhm... Loading any ontology included in the cycle yields the same imports closure, so what happens if instead of trying to upload bao_complete you try to upload bao_core? Bao_complete should be pulled in as an imports closure member, and saving the ontology by default adds missing declarations, so after the first load and save things might work all right. Similarly, loading manually with code like mine and saving a local copy should create a corrected file, which could then be uploaded to your tool, or modified as needed. |
ignazio1977
added a commit
that referenced
this issue
Sep 24, 2022
Ontology A imports ontology B, ontology B imports ontoloy A and ontology C, ontology C provides declaration for property P, ontology A uses property P. When loading A through its IRI, an ontology rename failure exception is raised. the reason is that A is parsed twice, once before and once after ontology C is parsed. However, when ontology C has yet to be parsed, there is no declaration available for P. This means that P is assumed to be an annotation property (only possible assumption, as the alternative is to throw a parsing error), and when the parsing of A completes, its id needs to be set with the value read from the ontology. However, at this point the two ontologies have the same id but not the same content - P has one guessed type and one parsed type, and the corresponding axioms differ. Hence, the api interprets this as two diffrent ontologies with the same id - which cannot coexist in the same manager. The full solution for this is for the parsers to work on two levels: ontology imports closure and entity declarations parsing, and axiom parsing. The ontologies to import and the declarations in each ontology would be parsed first, and once the closure has been computed, each ontology can be parsed with full knowledge of the entities declared - this removes the source of the error, in that there won't be any more cases of entities being used when their declaration has not been processed yet due to imports resolution and cycles. (This is how parsing is outlined in the specs, but it's not working exactly this way in practice and it's a considerable refactor for the current parsers.) (Other root issue: cycles in imports, this is not an indicator of a healthy ontology structure. It's allowed in OWL 2, but I cannot think of a scenario where the ontolgies wouldn't be easier to work with with imports refactored to not be cyclic). Luckily, when loading by IRIs, it's easy to avoid double parsing by adding the root ontology used at load time to the map of ontologies being imported, which is currently used to skip ultiple imports in the imports closure. The root was not included in this mechanism, for some reason - it should have been. Removing double parsing removes both issues, however the problem remains for root ontologies loaded from file or stream.
|
I have the same problem with the Ontopia ontology. I cannot understand how is it possible that the ontology is imported correctly in Protege. However it seems that the Ontology IRIs are parsed in a wrong way.
|
I have made a PR to try to solve this. Please check #1117 and protegeproject/protege#1181 (comment) |
|
Thanks but actually I use the owlapi directly from java. I reimplemented the import mechanism by myself... |
Ah ok. Yes the PR is actually to fix this in the owl api which in turn I use in protege. Edit: Ok i just saw your PR #1060 Regards |
|
issue should be solved, with fff1319 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If I have 2 ontologies that import each other and one of them has AnnotationAxioms, the ontology with AnnotationAxioms will not resolve properly due to how the ontologies are compared for equivalency. The first time an ontology is evaluated to see if it is equivalent, the object used is without the AnnotationAxioms. After it passes and is renamed, it is added to the list of ontologies in the closure. Then, after the fact, the AnnotationAxioms are added back into that ontology in the list. When the ontology is evaluated again later, it fails because the ontologies aren't equal because the object passed in doesn't have AnnotationAxiom whilst the one in the list of ontologies does.
Is this the intended design? Not processing AnnotationAxioms in the config is not an option for me either.
The text was updated successfully, but these errors were encountered: