Jump to: navigation, search


[edit] Status

Currently discussing at RdfAnnotations

[edit] Process

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.

[edit] Who

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

[edit] Architecture

We will surely have

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

[edit] Things to decide

Max: I suggest to use IBAW here.

[edit] issue: Use Java 5 annotations

[edit] issue: naming schema for properties

  • 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.

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

  • 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.

[edit] issue: should be simpler than ELMO

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

[edit] issues: use Dynamic proxies?

  • 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.

[edit] issue: use byte code creation

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

[edit] Unclear

  • 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

[edit] Other Topics

[edit] Logo Ideas


Personal tools