I think you need to unpack a bit what you mean by lightweight. If you mean the size of the .jar
files in a Jena deployment, you may be able to leave some of them out: icu4j.jar
, for example, is only used if your app handles internationalized data. However, if you are running a web-service, the deployment size probably doesn't matter.
Alternatively, if your focus is on performance, it would help if you could post some numbers and/or code snippets. There are some common pitfalls to avoid (such as not using the default OntModel
if you have no need of inferencing). Some of the newer persistent store adapters, such as TDB and SDB, may give significant speed-ups with larger volumes of data. Be aware though, that some of Jena's performance penalty comes from following W3C specs quite closely. Being lightweight at the expense of full compliance may impact your app in unexpected ways in the future, especially if you plan interoperation with other data services.
I guess the other interpretation of lightweight would be the programming model. I think it's fair to say that Jena pays a tax in following closely the RDF-triples view of the world. It's a bit like programming in assembler if what you really want is a high-level language. Jena's ontology API may help you, or you may prefer an OWL-centric API like http://owlapi.sourceforge.net/. Again, if you can post some specific examples of what you're trying to achieve we can give more tailored advice. The next version of Jena will support Java generics, which will definitely help smooth the API, but there's no scheduled release date for that yet.
Ian