Java OWL Persistence API (JOPA)

JOPA is a persistence API and implementation for accessing OWL ontologies. Its main features are:

  • Object-ontological mapping based on integrity constraints,
  • Explicit access to inferred knowledge,
  • Access to unmapped properties and individual's types
  • Transactions
  • Separate storage access layer

Downloads and Links

The project is hosted at github.com

JOPA artifacts can be downloaded from Maven central:

JOPA implementation:

Sesame (RDF4J) OntoDriver:
OWLAPI OntoDriver:
Jena OntoDriver:

JOPA requires Java 8 to compile and run.

Our github repository also contains some examples of JOPA usage:

JOPA Overview

The following image shows an overall view of an application using JOPA as its persistence provider. The diagram also shows how object-ontological mapping and storage access is decoupled in JOPA.

Object-ontological Mapping

JOPA enables mapping of ontology structures (concepts, individuals, object, data and annotation properties) to Java constructs (classes, instances, attributes). It is inspired by the JPA 2 specification for object-relational mapping. Analogously, JOPA does the so called object-ontological mapping (OOM). The mapping is based on a set of integrity constraints, which guard to contract between the object model on the one side and the ontology on the other. These integrity constraints apply a closed-world view to a (small) part of the otherwise open-world assuming ontology.

OOM in JOPA enables the application to access the more dynamic facets of the mapped ontology by exposing information such as unmapped properties (individual's properties not mapped by the object model) and individual's types. Perhaps most important in the mapping is access to the inferred knowledge in the ontology. Attributes of the entity classes can be annotated with the @Inferred annotation, which tells JOPA to load inferred values of the mapped property (or inferred types). This distinguishes JOPA from approaches like Empire and AliBaba, which do not make any difference between asserted and inferred knowledge. In JOPA, this difference is explicit, because the character of inferred knowledge has major impact on its usage. Because the knowledge is inferred from other knowledge, it cannot be directly edited by the application. Therefore, all inferred attributes are effectively read-only in JOPA.

JOPA has also support for easy-to-use SPARQL queries, which can be parametrized in the application. The underlying OntoDriver (see below) then executes the SPARQL query using the storage's querying facilities (Sesame SPARQL endpoint, OWL2Query for OWLAPI). OOM can also be used in connection with the query API, so query results can be directly mapped to entity instances.

The image above shows an example of an entity declaration used by JOPA. This entity class shows the following features of JOPA:

  • The annotation at line 13 declares the ID to be automatically generated, so when an instance without URI is persisted, a unique URI will be generated for it.
  • Lines 16-23 declare several attributes mapped to OWL data properties in the ontology.
  • Lines 25-27 declare an attribute referencing another entity class. Such attribute corresponds to an OWL object property. The participation constraint on line 25 specifies that at least one value of the property has to be present. Mapping on line 26 specifies that the attribute value should be loaded eagerly (by default, object property attributes are loaded lazily).
  • Types specification declared on lines 29-31 contains all ontological classes of which a particular Student is instance. These types do not include the class declared on line 10. The types are declared as @Inferred, so inferred OWL classes will be included in the value. The @Inferred annotation makes the field effectively read-only - its value cannot be directly changed in JOPA.
  • The properties declaration on lines 33 and 34 gives the application access to ontological properties not mapped by the object model. Therefore, if the ontological individual has other properties besides those mapped by this entity, they will be accessible through this attribute.

The following image shows the very basics of JOPA usage. Notice the similarity to JPA.


OntoDriver is a software layer used to decouple JOPA from actual storage access. This decoupling enables ontology storages to be switched without any impact on the application code. The OntoDriver API represents an API which every implementation of OntoDriver has to support and which is used by JOPA to access the ontological data. Internal structure of OntoDriver is specific for the underlying storage implementations. The concept of OntoDriver is very similar to a JDBC driver in the relational database access. However, in contrast to JDBC, where SQL statements are used to access to storage, OntoDriver API provides a set of dedicated operations (find, persist etc.), which provide a more fine-grained control over the storage access.

Jena, OWLAPI and Sesame (RDF4J) OntoDriver implementations exist.


  • P. Křemen and Z. Kouba. Ontology-Driven Information System Design. IEEE Transactions on Systems, Man, and Cybernetics: Part C, 42(3):334–344, May 2012.

  • Ledvinka, M. - Křemen, P.: JOPA: Developing Ontology-Based Information Systems. In Proceedings of the 13th Annual Conference Znalosti 2014. Praha: VŠE, 2014, p. 108-117. ISBN 978-80-245-2054-4.

  • Ledvinka, M. - Křemen, P.: JOPA: Accessing Ontologies in an Object-oriented Way. In Proceedings of the 17th International Conference on Enterprise Information Systems. Porto: SciTePress - Science and Technology Publications, 2015, p. 212-222. ISBN 978-989-758-096-3.

  • Ledvinka M., Křemen P. (2015) JOPA: Stay Object-Oriented When Persisting Ontologies. In: Hammoudi S., Maciaszek L., Teniente E., Camp O., Cordeiro J. (eds) Enterprise Information Systems. Lecture Notes in Business Information Processing, vol 241. Springer, Cham