sommer
Project home

Introduction

Sommer is a very simple library for mapping Plain Old Java Objects (POJOs) to RDF graphs and back. Sommer stands for "Semantic Object (Metadata) MappeR". In German it also means "summer", the season opposite to winter, when animals no longer hibernate. In French a "somme" is both the sum of things as well as a little rest.

We can illustrate the mapping by the blue arrows in the following figure:

On the yellow background you have the class definitions, which everyone knows how to write in Java and which would be written out using the RDFS or OWL vocabulary in RDF. Below you have instances A, B, C, D in the RDF section and their equivalent mapped versions a, b, c, d in Java .

So in Java we have the call
a instanceof Group
return true, and and in rdf/n3 we have the following relation
:A rdf:type foaf:Group .

In both cases we are expressing that there is a Group which contains 3 members, all of which are agents, and in particular one of which is a Robot and the other a Person.

The modelling in Java is slightly different in this case from the one in RDF, as it is easier to model nary relations in java as lists. One could just as well have expressed the same in RDF as a list, it's just neater not to.

In Action

This library was initially developed to help build BlogEd on top of the Sesame RDF triple store, in order to avoid the pain point of having to deal with the basic statement model of those frameworks, as illustrated below.
This library allows developers to use simple java objects in the usual way without having to manipulate RDF triples. So instead of having to write something like

    String rdf="https://www.w3.org/1999/02/22-rdf-syntax-ns#";
    String foaf="https://xmlns.com/foaf/0.1/";
    Graph gr = new Graph(new URL("https://get.the.data.somewhere.com"));
    Set<Statement> agents = gr.getStatements(null,rdf+"type",foaf+"Agent");
    for (Statement s: agents) {
        Set<Statement> mboxs = gr.getStatements(s.getSubject(),foaf+"mbox",null);
        Set<Statement> names = gr.getStatements(s.getSubject(),foaf+"name",null);
        System.out.println(names.iterator().getNext() + "has mailbox "+ mboxs.iterator().getNext());		
    }	

which brings in all kinds of RDFisms like Statements, Properties, Values, ... which is extreemly verbose, painful to write and prone to mistake, as well as a refactoring nightmare and which does not use the native Java classes, one can write the following:

    Mapper mapper = MapperManager.getMapperForGraph("https://eg.com/feed1.n3");
    Collection<Agent> people = mapper.getAllObjectsOfType(Agent.class);
    for (Person p: people) {
        Collection<URI> mboxes = p.getMailboxes();
        Collection<String> names = p.getNames();
        System.out.println(names.iterator().getNext() + " has mailbox "+
                     mboxes.iterator().getNext());
    }

The above code is a lot easier to understand. It works much better with refactoring tools. And of course such classes will work together much more harmoniously with other libraries. Since one can store any structure in RDF this could also come to be the universal way to map java objects to data stores.

All that is needed to do this is to annotate one's classses and fields with @rdf annotations like this:

@rdf(foaf + "Agent")
public class Agent {
    public static final String foaf = "https://xmlns.com/foaf/0.1/";
    @rdf(foaf + "mbox") private Collection mboxes;
    @rdf(foaf + "mbox_sha1sum") private Collection mbox_sha1sums;
    @rdf(foaf + "jabberID") private String jabberId;C
    @rdf(foaf + "aimChatID") private String aimChatId;
    @rdf(foaf + "yahooChatID") private String yahooChatId;
    @rdf(foaf + "msnChatID") private String msnChatId;
    @rdf(foaf + "weblog") private Collection weblogs;
    @rdf(foaf + "tipjar") private FoafDocument tipjar;
 
...
    public Collection getLogos() {
          return logos;    
    }    
    public void setLogos(Collection logos) {
           this.logos = logos;    
    }
...
}

As shown by a number of examples in the subversion repository. Note, that the source code there also makes use of the @inverseFunctional annotation. I am no longer sure if this should really be in the java code. It adds little there. This should probably left in the ontology. The mapper should be able to access that ontology and get that extra information there. This makes the java code much cleaner.

History

As mentioned above, this library was developed whilst working at incorporating the Sesame database in BlogEd. Those frameworks are built very close to the rdf data model of (subject, predicate, object), which is good as far as it goes, but not very nice to program to in Java.

The first versions of this library were written against java 1.4 and the mapping as expressed through a very ad hoc convention of naming variables. This library is available in the version_0.2 directory. It works agains the Sesame 1.2.x libraries.

With Java 5 it becomes a lot easier to express this mapping using annotations. I first wrote about this more at length on my blog Java Annotations and the Semantic Web. (For a lot more on the stunning advantages of RDF see that blog).

The next version (0.4), which should be out shortly, will be written for java 5.0, use java annotations and Aspect Oriented Programming to map POJOs to RDF graphs (so provenance will be taken into account). See my recent blog entry. I am starting to work with Sesame 2.0 and the Javassist AOP library. One has to start somewhere. I envisage that one could modularise this framework to work with other RDF libraries such as Jena, or other AOP tools such as AspectJ or JBoss AOP. Even though at first there will be all kinds of library dependency leakages (I need a proof of concept first), I hope that this library will be compatible with any number of implementation choices.

Please join the users mailing list. If you would like to help out on the project just ask. I'll give you access to the subversion commit. I keep being pulled on to other things, and I develop this library as I need it for my other project.

Other Projects

Elmo

We have been working with other projects such as Elmo to start coming to an agreement on the meaning of the required annotations. Perhaps this should be the subject of a JSR. The Elmo project for example has a script that can produce an annotated class hierarchy from an Ontology, such as the AtomOwl ontology, which is also being developed here.

JSR311

JSR311: The JavaTM API for RESTful Web Services, is adding a few simple annotations to make it easier to map java to web services (see the Jersey project). One of these is to add @UriTemplate("/customers") on a Java class. What this is really doing from this project's point of view is just giving a default mapping for instances of java objects. So(m)mer gives mappings for classes and relations of classes, and at present extracts the names from the rdf graphs it finds on the web. Objects that may be created locally have anonymous names.