Home

Similarly as with "ont," the orr-ont service mainly provides a REST API for client applications to access and manage a repository of ontologies, also including management of user accounts and organizations. But there are important differences in implementation and the underlying technologies. The following is a comparison between "ont" and "orr-ont" with respect to various aspects. This is preliminary, not exhaustive, but should give a good sense of the intent.

Aspect	ont	orr-ont
Request for latest version	Conversion always made from the versioned form	Immediately returned
Output formats	RDF/XML, N3	RDF/XML, N3, JSON-LD
Request in other format	Conversion always made	Conversion only once then cached
Ontology versions stored in	Versioned form	Un-versioned form
"self-hosted" dispatch	Supported	Supported
Organization (authority) support	Very minimal	Better supported (1)
Permissions	Minimal	Significantly improved (2)
Main dependencies, database	BioPortal, MySQL, AllegroGraph	MongoDB, AllegroGraph
Language/dispatch mechanism	Java / Servlet	Scala / Scalatra

(1) Organizations are explicitly modeled in orr-ont. All ontology submissions are associated with corresponding organizations. An organization has members, and only members can register ontologies for that organization.

(2) Initially, Basic Authentication, which, along with HTTPS, should be good enough.

In general, because of the new and simplified mechanisms in orr-ont, a number of benefits are expected:

• Easier installation of main dependencies (MongoDB, AllegroGraph)
• Better performance (possibly very significant)

Also, the code is simplified and should be easier to maintain and extend thanks to the use of a modern Web micro-framework as provided by Scalatra, not to mention the use of Scala itself. Other frameworks could also be considered (in particular Akka HTTP, but Scalatra is proving to be an excellent alternative at least for the time being.