-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider using a JSON representation instead of the obo file format #2
Comments
Hey @cmungall -- this is great news! I fully support the deprecation of OBO for a standard serialization format. Of serialization formats that have universal support, I can think of XML, JSON, YAML, and TSV. I think JSON is the best choice, and have myself used it to encode Hetionet v1.0. Users will still need to understand the data model (what the JSON attributes mean) but will no longer have to struggle with text parsing. The problem with OWL is that it's too complex for most users: you can't just look at the raw text and understand what to do. I wrote this package and its minimal amount of tests based on my specific use cases. Given the vague and odd specification of the OBO format, I would like to rely on this package as little as possible. So one thing that would be great is if OBOFoundry started releasing their ontologies in the obographs JSON format. Larger picture, I think there have been two main pain points for ontology adoption. First is documentation and second is readability/operability. The documentation issues are slowly getting better, but the terminology is still daunting for outsiders. For example, I still don't fully understand what an "axiom" is. So pardon my ramble, just wanted to jot down my thoughts. Thanks for keeping me in the loop! |
In defence of OWL, the intention is that you use Protege or a similar interface to explore it, rather than looking at raw text. But this is a bit of an ivory tower attitude, in reality most coders need fewer levels of abstractions between them and the information they are trying to get at. (the OWL core language is actually amazingly simple - it's just a notation for writing simple set-theoretic expressions over a domain of unary and binary relations - but there is a big gap between this and bioinformatics use cases, and a huge amount of complexity involved in layering this notation onto the RDF/XML concrete form).
Your implementation seems far more robust than other implementations I have seen. But as you point out it's fundamentally hard to check for edge cases given the complexity of the OBO spec (complexity that arises out of the evolution of what was intended to be a simple format - a lesson i there)
Great. We have more work to do to make this a standard, but we can have some release pipelines include this, with the understanding the structure may change, to allow early adopters a chance to test. Thanks for the comments on the documentation, fully agree |
The people need programmatic ontology access in Python. Out of curiosity, do you know the best way to import OWLs into a Python data structure?
Yes "amazingly simple" 😸 .
Awesome, happy to be a tester. Just ping me wherever and whenever the time has come! |
On 25 Oct 2016, at 14:51, Daniel Himmelstein wrote:
rdflib is slow, and too low a level of abstraction. It depends what you
Think Venn Diagrams!
OK, will do |
e22bf7b adds a section to the README that mentions the I personally use OBO Graphs JSON whenever possible. The sad reality however is that for many ontologies, you'll have to try to parse all three formats and if lucky at least one format will work 😸 . |
Note that have a proposed JSON representation of OBO that would obviate the need for special purpose parsers. Your comments as a developer would be most welcome:
See also: mschubert/python-obo#2
The text was updated successfully, but these errors were encountered: