Provide client/server js interface for use from browsers. Another for IPC?

[sesuncedu]

Many potential applications of OWL are web based. An idiomatic javascript API supporting a subset of use cases could greatly simplify adoption.

@cmungall developed a wrapper for use with the JVM JS engine ; code running in the browser has different requirements (e.g. providing async access to nearby classes (and their labels) in a hierarchy, in suitable JSON or protobufs; locally caching ontology fragments, etc).

A different style of API may be useful for integrating with non-jvm languages. XML has proven somewhat heavyweight (viz Konclude). JSON may not be sufficiently bette. A different marshaling format might be suitable (MPI? protobufs?)

[cmungall]

This was the jvm js engine. https://github.com/cmungall/owljs It uses RIngo, which seems to be largely abandoned.

Not sure if this counts as idiomatic: https://github.com/geneontology/obographs It was designed specifically not to structurally mirror either the OWL specs, or the OWALPI, but instead to make it easy for simple operations typically done by domain-specific applications. (it's not an API, just a JSON schema)

For a REST API onto OWL, see @balhoff's https://github.com/phenoscape/owlery/

What kind of applications do you have an mind? On the one hand there are applications like WebProtege. On the other there are domain-specific ones that need specific kinds of ontology operations.

[sesuncedu]

By idiomatic I'm thinking of something that fits naturally with AngularJS / JQuery UI etc. AngularJS may be a good fit.

The answer to your final question is yes web protege and domain specific and domain specific web protege :-)

My starting point was thinking about some of the custom applications built using web-protege. Most of these have been oriented towards building vocabularies (also they have mostly used older style protege - right @matthewhorridge ?)

However, I also had in mind applications that mostly just use vocabularies e.g.

• searching / browsing a vocabulary to find terms for use when annoting annotation (with appropriate fetching of preferred labels, as well as scope notes, definitions, etc.
• provide support for hierarchical filtering of result sets (in-memory / remote).
• make owl instances look like js objects ;
• use ontology or reasoner to classify js objects, updating prototype (creating faux-totype if necessary), and filling in inferable property values.
• computing possible/probable value sets / ranges for underdetermined applicable properties

Filling in property values, or at least narrowing down the range of possible values, is intended to use KB to support data entry/knowledge acquisition.

The actual integration with Angular etc. is probably outside the scope of OWLAPI; however, providing efficient support for finding all the known property values for an instance, as well as the available value spaces are drivers for other changes in the API (some of these changes would really benefit from information hidden inside the reasoner.

[sesuncedu]

BTW, on a phenotypical SMH moment on the mailing list for a forum related to ontology, some spark, based on reading a popular science article about stem cells, came up with the brilliant idea of creating an ontology of cell types. But what could one possibly call such a Cell Ontology? Also http://www.obo.co.nz/