Jump to: navigation, search


Currently discussing at RdfAnnotations


We want to explore how or if we can combine our efforts to create fewer, better tools for mapping RDF to OO and back again.

Peter: My fear is that each triple store has a number of extra features and in some cases not using these features would hurt functionality or performance. (That said I dont' know RDF2Go and what it does in this respect.)

Max: It seems, we might need to agree on something like RDF2Go in order to overcome the triple store dependency. The currently proposed API can be inspected here.

Some tools generate Java code/interfaces from ontologies

  • we could agree on some annotations here

Some tools generate ontologies from Java

  • we could agree on some annotations here

Some tools use annotated Java with RDF

  • we could agree on some annotations here
  • James: Elmo and Sommer use very similar @rdf annotation, but Elmo annotates methods on Java interfaces and Sommer annotates fields on Java classes.


Who is willing to invest some time to make a new, better RDF-OO-tool, based on experience gained from RDFReactor, Elmo and RDF2Java.


We will surely have

  • runtime
  • generator
  • command line interface
  • maybe ANT goal
  • maybe Maven2 mojo

Things to decide[edit]

Max: I suggest to use IBAW here.

issue: Use Java 5 annotations[edit]

issue: naming schema for properties[edit]

  • idea: addX(o), addAllX(o[]), removeX(o), removeAllX(o[]), setX(o)
  • idea: one getter/setter: In this case the getX() would always return a java.util.Set.
  • pro: One can always create wrapper methods if needed.

issue: Use RDF2Go to abstract from triple store vendor[edit]

  • pro: makes Tripresso more useful
  • pro: Leo: I think that people should use rdf2go in as many projects as possible, and not jena or sesame directly. Especially in reusable frameworks (for example, in a generic toolkit such as gnogno)
  • pro: Leo: I would think that something tripresso-like on top of rdf2go is needed
  • con: James: native api support is also just as important. The rdf2go implementations that I have seen wrap the native api, causing an extra step for every Resource/Literal that is read from the repository. During early Sesame 2.0-alpha development we had tried a similar approach, having the repository api wrap the sail api, but reverted after some performance measurements where done.

James: For Elmo to support RDF2Go only the 50 or so classes in elmo-sesame need to be ported (half of which just convert between xsd literals and java.lang). Although I personally don't have the time to lead such an effort, I am available to provide technical support.

issue: should be simpler than ELMO[edit]

  • pro: Leo: so I would favor a port of elmo on rdf2go, but making it simpler.
    • @@ at leo: what is too complicated about ELMO?

issues: use Dynamic proxies?[edit]

  • contra:because debugging becomes much harder (max)
  • pro: Leo: it is far more powerful, clean
  • pro: Leo: it creates less code
  • con: What I hate about ELMO is that its a little complicated and it dynamically generates code, which is compiled during runtime (at least how i understood it)
  • con: Leo: I also think that the code-injection is a black art, but alas, I have no clue how to do it right.

issue: use byte code creation[edit]

  • pro: James: It was decided to use byte-code creation in Elmo instead of Java Proxy in Elmo, because byte-code creation executes faster.


  • Leo: the key is auto-generated java.Proxy objects that auto-implement auto-generated interfaces using invocationhandlers, or?
    • Max: even Java dynamic proxies NEED interfaces which need to be compiled

Other Top.css[edit]

Logo Ideas[edit]

Error creating thumbnail: Unable to save thumbnail to destination