Update OBO parser to use oboformat 5.X (obo 1.4) about owlapi HOT 11 CLOSED

The license on Google Code is displayed as New BSD License although there isn't a LICENSE file or a reference to the license in the pom.xml file to confirm it.

@hdietze @cmungall Can this code be integrated into owlapi easily?

from owlapi.

We're using this reference parser code for WebProtege. I had to write an OWL API parser class to wrap the functionality plus a factory for the parser. Also, the reference OBO parser will happily parse some turtle files as OBO files - be careful of this.

from owlapi.

I noticed it will be happy with manchester owl syntax as well :-) I've put it last in the order of those to be tried.

from owlapi.

Regarding licenses, I had a chat with @cmungall on the oboformat list about this - a LICENSE.txt might be added to confirm the license and maybe Apache license can be added.

From our point of view, including BSD/Apache code should be fine, as the rest of the OWL API is either Apache or LGPL, and that's the most restrictive bit for a final user. That's my reasoning, but if anyone has experience in the area please set me straight :-)

from owlapi.

I hadn't noticed the same behaviour on Manchester Syntax. It needs to fail hard if the ontology isn't an OBO file... even if it's the last parser in the list.

from owlapi.

License wise, as far as I can tell including BSD code is doable without problems.
I plan to add a header with references to the original authors and repository, and include only the parser code and not the test and utility classes, as this would complicate maintenance and the changes needed.
I'll maintain the split project in a separate git repository to simplify rebasing and just move over changes to the parser, ideally.
I'd prefer it to be a separate project that could just be imported as a dependency, but in my experiment so far there are dependencies on parsers code. This would mean that release X of the obo project would need to depend on, say, parsers-3.4.6, then OWLAPI 3.4.7 would depend on version X and transitively on parsers 3.4.6 and 3.4.7 - chaos. And release X cannot be released depending on parsers 3.4.7 because that version is not released until after release X is completed - so it's necessary for obo to be a module in OWLAPI rather than an external project.

from owlapi.

parse non-fail fails: unfortunately it's possible to write omn that looks like a giant OBO ontology header - the header syntax is very forgiving.

According to http://www.w3.org/TR/owl2-manchester-syntax/
every document must have an ontology declaration:

ontologyDocument ::= { prefixDeclaration } ontology
ontology ::= 'Ontology:' [ ontologyIRI [ versionIRI ] ] { import } { annotations } { frame } 

So we could make this a reserved word in OBOF such that a header tag cannot be Ontology (upper case - the lower case 'ontology:' is used in obof)

However, the OWLAPI omn parser permits ontologies without this.

We could add everything in omn as reserved words that can't be used in obof headers - then only empty documents would be ambiguous.

But this is a bit annoying.

How about instead we introduce the notion of a proper OBO document, which must have 1 or more frames. We can add a switch to the parser so it throws on encountering a non-proper document. The OWLAPI parser would officially be a proper OBO document parser.

This would prevent you from writing pure "importer" ontologies in obof, but really, you shouldn't be doing that anyway. It could also potential some kind of ontology generation workflows where an empty ontology may be an allowed output. But again, don't do that.

from owlapi.

I'm not sure how best to handle the dependency issue. If we can punt for 2 weeks I can discuss it with Heiko. Maybe the best approach is to refactor the code to be a proper part of the OWLAPI. We would still need to make modifications from time to time but being in github makes this easy.

from owlapi.

No problem for me, we don't have deadlines.
I was actually wondering if this should be done before the next release or after - I could get a release out and then start playing with the parsers.

from owlapi.

A related enhancement may be to enable targeted parsing based on content types so that if a user expects a Manchester Syntax document then it will not attempt to parse using OBO and vice-versa.

On my fork this is implemented by extending OntologyDocumentSource (and implementations) to include a new optional field for the content type. That content type is matched to OWLOntologyFormat (using a new OWLOntologyFormatFactory interface to enable fresh clones easily as necessary), and from there it is matched against all registered parsers.

I originally needed to do this due to a bug where invalid RDF/XML documents were being parsed validly as OWL-XML in some cases (not the same as issue #47 but similar outcome), but it would also be applicable to this case.

from owlapi.

I've split the comments on this thread on issue 80 and 81, to be considered for implementation. The OBO parser has been integrated as a module, and the oboformat project at https://github.com/ignazio1977/oboformat contains all the changes made to the original code, plus all tests not included in the OWLAPI tests

from owlapi.