search

geneontology / obographs

Basic and Advanced OBO Graphs: specification and reference implementation
64 stars 12 forks source link

Update README.md #15

Closed cmpich closed 7 years ago

cmpich commented 7 years ago

Why do you use "lbl" as a key for the term/class name? Why not "name"? Also, I would be in favor of using "subject", "predicate" and "object" instead of the three-character abbreviations. It'll be just a tad clearer.

I would add in the motivation-section that JSON is a very popular syntax that has a lot of support in various software. It is more expressive than the OBO syntax and less complicated than OWL.

OBO is a subset of OWL, i.e. OWL is a superset thus can express all axioms found in OBO. How does OBO Graph compare with OWL? can they both express each other's axioms and properties? Are they equivalent? Can I convert from one to the other and back and arrive at the same state?

cmungall commented 7 years ago

lbl: this is to retain compatibility with bbop-graphs, which is currently used in a number of client applications. I will discuss this with @kltm when he is back in a few weeks. Same with sub/obj.

+1 for the motivation comments

Conversion: there is not yet a converter to go back from obog to owl. This should just be plumbing though.

Currently there are various axiom patterns in OWL that do not have a matching pattern in obog, so owl->obog is lossy. The plan is to catch these in a very generic JSON pattern that mirrors OWL functional syntax. But (sweeping possibly unfounded generalization ahead) most of the OWL constructs and patterns of use to a typical bioinformatics application should currently be convertible. E.g. if you have GCIs with unbounded levels of nesting in the LHS then it won't convert

Having said this, I am not 100% confident all of ZP is convertible..

kltm commented 7 years ago

There's actually a simple reason for this: given our use the extra characters actually added a non-trivial unnecessary payload and a noticeable affect on the UX on clients in some use cases. We actually had single letter field names at one point, but felt it would be too obtuse. This format is meant to be human-readable/editable, but the main point was a light computer format for basic mathematical graphs.