The MICO project and especially the MICO platform stores the metadata results of extractors as RDF. To enable an easy entry point for non Semantic Web developers we want to provide the possibility to work on objects rather than dealing with triples or [SPARQL] queries. Therefore we require an framework for mapping objects to RDF and vice versa.
The framework should allow us to:
- work on objects (annotation-based approach)
- map objects to RDF and back
- persist data into triple stores
- query data from triple stores
We need to identify a Java library capable of respecting these priorities. The candidates we consider are:
Empire is an implementation of the Java Persistence API (JPA) for RDF and the Semantic Web. Instead of another implementation of relational databases, Empire implements JPA for RDF and SPARQL. Thus allowing developers who are familiar with JPA, but not with semantic web technologies like RDF, to make an easy transition into the Semantic Web. JPA is a specification for managing Java objects, most commonly with an RDBMS; it’s industry standard for Java ORMs .
The Semantic Object (metadata) Mapper mapps is a very easy to use library for mapping Plain Old Java Objects (POJOs) to RDF graphs and back. Som(mer) is annotation-based, this means that Som(m)er allows to declare RDF directly as Java annotations .
jenabean uses Jena’s flexible RDF/OWL API to persist java beans. It takes an unconventional approach to binding that is driven by the java object model rather than an OWL or RDF schema. jenabean is annotation based and does not place any interface or extension requirements on your java object model. By default jenabean uses typical java bean conventions to derive RDF property URI’s, for example, the java bean property “name” would become RDF property “:name”. jenabean allows for explicit binding between an object property and a particular RDF property .
AliBaba is an RDF application library for developing complex RDF storage applications. AliBaba is the next generation of the Elmo codebase. It is a collection of modules that provides simplified RDF store abstractions to accelerate development and facilitate application maintenance. The AliBaba contains the following modules :
- AliBaba’s object repository is able to provide programmers with increased expressivity and a simplified subject-oriented programming environment. This can accelerate the time to market and reduce maintenance cost down the road.
- The Optimistic SAIL of AliBaba is designed to improve the performance of small write operations by supporting concurrent write transactions and protects your data from data inconsistency issues when snapshot and serializable transactions are enabled.
- AliBaba’s keyword SAIL allows quick and easy indexing of keywords for RDF resources.
- AliBaba’s two phase commit BLOB store allows to store binary or text documents in an integrated binary and RDF store.
|Last Update||8 month ago||6 years ago||5 years ago||1 month ago|
|License||Apache 2.0 License||New BSD License||Apache 2.0 License||Custom BSD License|
After extensive testing of each framework, the conclusion was that no framework met all our requirements. It is noticeable that most libraries are no longer maintained or lack full documentation. Empire for example is a very versatile tool, but has poor documentation and is not easy to use. Som(m)er is also poorly documented, but was very easy to integrate in our test environment. It however lacks the option to query triple stores and the last update was six years ago. Jenabeans is also easy to use and in addition supports querying. Jenabeans also has a wiki page with basic usage documentation.
Nevertheless the best option for our needs was AliBaba. AliBaba has more or less the same functionality as jenabeans, but more importantly extends Sesame which was a deciding factor – because the MICO platform also uses Sesame. This capability brings two major advantages compared to the other frameworks:
- First it allows us to persist the created data directly using AliBaba.
- The second advantage is the possibility to query the object repository using custom SPARQL queries on the one hand. On the other hand AliBaba allows us to work with objects. This means, that AliBaba provides simple getter-functions to query whole groups of data, i.e. all annotations created by a specific extractor.
Another point why we decided to use AliBaba was the fact, that it was recently maintained. We hope that the development will continue, so that we have more benefits in the future.
Finally you should keep in mind that this was a project specific decision. Jenabeans for example is very similar to AliBaba and would be a great choice for Jena-based systems.