-
Notifications
You must be signed in to change notification settings - Fork 5
Home
ONT-API is a RDF-centric OWL-API implementation, which is built over Apache Jena framework. Thus, in addition to the OWL-API interfaces, it provides a Jena-way to interact directly with ontological graph.
Apache Jena is a framework to work with RDF, but its OWL support is limited to outdated OWL-1 specification.
The modern OWL-2 specification is fully supported by OWL-API,
but it is an OWL-centric library and, by default,
it does NOT provide an adequate opportunity to work with an ontological RDF Graph: an OWLObject is a primary unit there, and if the incoming RDF data cannot be mapped into OWL, then it is simply lost.
ONT-API is an implementation of the OWL-API interfaces over Jena,
thus, in addition to the structural representation of ontology (axioms), it is possible also to work with underlying graph directly.
This can be useful to the Jena-users since it allows to use API that meets the modern OWL specification along with other Jena-compatible products.
This can also be useful to the OWL-API users because the RDF based solution is more flexible and universal,
which allows solving a number of OWL-API typical problems.
The downside of this approach is perhaps different memory consumption and different performance, which are not always better.
The principle of ONT-API is that all information is kept and remains in the very graph (which are not necessarily stored in memory), and if a set of triples from this graph corresponds to the axiom, then we can read them in the form of this axiom (i.e. in the structural view). Similarly, the writing of axioms goes in triplet form only: axioms are not stored in separately (if not to taking into account caches). So, if OWL-API with its default implementation offers classic mapping RDF to OWL and back, in ONT-API instead there is a reading. In the ONT-API reading and writing an ontology from a file or a stream happen through Jena RIOT, however, the original OWL-API mechanisms to read/write also remain working, and even are used explicitly if the data format is not supported by Jena (e.g. Functional Syntax, Manchester Syntax, OWL/RDF, etc). ONT-API supports all OWL-API features and options, but they are somewhat expanded. Instead of the original OWL-API interfaces in ONT-API there are the overridden ones with several additional methods to access to Jena-API. Also, there are new configuration options and the policy with exceptions has been changed a little. Nevertheless, it is always possible to use the original OWL-API or its parts in conjunction with ONT-API, for example, you can just copy an ontology from the ONT-API manager to the OWL-API-impl manager and vice versa.
ONT-API IS OWL-API, and can be used in all places where OWL-API is used. If you don't accept this, then you're, probably, don't need ONT-API at all.
The only factory to access the system is com.github.owlcs.ontapi.OntManagers.
The native OWL-API factory org.semanticweb.owlapi.apibinding.OWLManager (located in OWL-API-apibinding module) cannot provide ONT-API.
ONT-API does not support injections (javax.inject.Inject),
and, therefore, org.semanticweb.owlapi.apibinding.OWLManager cannot return our Jena-based implementation,
but the opposite is true: com.github.owlcs.ontapi.OntManagers provides both implementations - the default reference impl (OWL-API-impl) and this RDF based impl (ONT-API).
See examples page.
See maven page.
The project contains tests obtained from the OWL-API-contract (an modified copy-paste of the version 5.0.4), which show the working capacity of ONT-API. Also, there are a lot of ONT-API specific tests. Currently, there are about 6k test-cases.
See memory consumption and performance pages.
ONT-API supports format syntax languages of both Apache Jena and OWL-API. By default, when loading and saving ontology, the Jena mechanisms have more priority than OWL-API ones. For additional details see formats page.
See references page for more info.