Closed GoogleCodeExporter closed 9 years ago
This is a problem in the source ontology; in the following line:
def: "A family_1_base_pair is an RNAO_base_pair in which the two RNA
nucleotides interact by edge-to-edge hydrogen-bonding between the Watson-Crick
edges of each base and in which the glycosidic bonds of the two nucleotides are
oriented "cis" relative to each other." [RNAO:ROC]
the quoted "cis" should be escaped. E.g. \"cis\"
I will contact Colin to update his xslt that generates this (or switch straight
to using this code)
We should also make the errors more informative. It shouldn't produce a null
obodoc - it shouldn't try to recover from a parse exception
Original comment by cmung...@gmail.com
on 7 Jul 2011 at 11:32
Thanks for your quick response. I can perform some formatting cleanup before
parsing in the meantime. I'm wondering if perhaps I am misinterpreting the use
of this library. I am using oboformat via the Java API to parse the obo
ontologies at the OBO foundry (I had been using the OWLAPI parser but your new
parser seems to capture additional semantics in the OBO format). A significant
number of these are failing for one reason or another. Is the library intended
to focus on the newer 1.4 OBO format and not the 1.2 which is what most of the
OBO ontologies in the foundry are formatted as? Thanks for any
feedback/suggestions.
Original comment by cszamu...@gmail.com
on 10 Jul 2011 at 6:27
Every obof1.2 file is a valid obof1.4 file, so you should be able to use this
library for any obo file you can download from obofoundry.org
Having said that, I would not use OBODoc objects directly. The main purpose of
this library is to translate into OWL (or back to OBO). It isn't really
optimized for the kinds of operations you'd want to do in an application. The
OBODoc model rigidly mirrors obo-format, including all the legacy flaws of this
format.
You should be able to use the OWLAPI over the converted ontology. I can see the
temptation to use the OBODoc objects - it is much simpler to do "obo-type"
things such as finding all the synonyms together with their scope. This is
possible with the OWLAPI but is a lot more verbose due to the generic nature of
OWL.
If this is the case then I would recommend
http://code.google.com/p/owltools
This provides a convenience layer on top of the OWL API for "obo-type"
operations. It also bundles the org.oboformat parser.
This may seem somewhat circuitous but it is the most robust strategy in the
long term
Original comment by cmung...@gmail.com
on 10 Jul 2011 at 8:02
Hi again,
I'm actually only interested in converting OBO to OWL. Once I have the OWL
file, then I can do other stuff with it (like generate a SKOS vocabulary). So,
from your message it would seem that I am back to the question of handling
failed OBO files. Would you expect that OBOParser() would successfully parse
all of the OBO ontologies available at the foundry? As I mentioned above, in my
hands many fail the parsing step.
Thanks.
Original comment by cszamu...@gmail.com
on 13 Jul 2011 at 7:54
> Once I have the OWL file, then I can do other stuff with it (like generate a
SKOS vocabulary).
A shame to throw away all the semantics to use SKOS
> So, from your message it would seem that I am back to the question of
handling failed OBO files. Would you expect that OBOParser() would successfully
parse all of the OBO ontologies available at the foundry? As I mentioned above,
in my hands many fail the parsing step.
There's lots of active development going on right now to fix remaining
conversion issues (mainly around ID conversion). Conversion should work for all
Foundry ontologies soon, hopefully within the next two weeks.
Original comment by dosu...@gmail.com
on 13 Jul 2011 at 8:11
There are still a few ontologies that do not parse. This is due to actual
syntax errors in the files. The maintainers have been notified.
Original comment by cmung...@gmail.com
on 13 Jul 2011 at 8:17
Original issue reported on code.google.com by
cszamu...@gmail.com
on 7 Jul 2011 at 8:01