Home

Updated contents at https://mmisw.org/orrdoc/from2to3/

---

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 underlying technologies, implementation approach. 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
HTTP interface	Rather ad hoc	✅ RESTful
Explicit "voc2rdf" and "vine" formats	no	✅ yes (1)
Support for multiple classes in "voc2rdf"	no	✅ yes
Request for latest version	Conversion always made from the versioned form	✅ Immediately returned
Output formats	RDF/XML, N3	✅ RDF/XML, RDF/JSON, JSON-LD, N3, Turtle, N-Triples, N-Quads
Request in other format	Conversion always made	✅ Conversion done only once then cached
Ontology versions stored in	Versioned form	✅ Un-versioned form
Organization (authority) support	Very minimal	✅ Better supported (2)
Authentication	Limited security	✅ Significantly improved (3)
Authorization/permissions	Minimal	✅ Significantly improved (2)
"self-resolvable" URI HTML dispatch	Redirection to separate UI webapp	✅ Direct dispatch (4)
Database dependencies	BioPortal, MySQL	✅ MongoDB
Triple store dependency	AllegroGraph	AllegroGraph
Language / HTTP mechanism	Java / Servlet	✅ Scala / Scalatra
Unit/integration testing	Minimal	✅ Comprehensive

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(5), not to mention the use of Scala itself.

---

(1) The explicit formats allow not only more effective internal handling, but facilitate the support of some user-level features (e.g., preservation of column order in "voc2rdf" vocabularies.)

(2) Organizations are explicitly modeled in orr-ont. An organization has members, and only members can register ontologies for that organization. (A user can also register his/her own ontologies.)

(3) Authentication is based on JSON Web Tokens and Basic Authentication.

(4) Direct dispatch so the original ontology URI (URL case) is retained in the browser URL field. (Redirection has often caused confusion regarding the proper URI for ontology identification.)

(5) However, other HTTP frameworks, apparently much more actively maintained, may be considered in a future version including Akka HTTP and Play.