Generating full Java interface-extends hierarchy in RDFReactor output

[Stu Btwotwo]

Hello RDFReactor Fans,

My group is getting great results with RDF Reactor, bound using the Jena back end (ModelImplJena).  
We do our builds with the v5.0.1 maven plugin, which works just great.   Thanks again for the work to create and
maintain it!    Just for fun I will mention that a few of the ontos we process with it now are called MetaDir and
CircusRecipe, which represent abstractions for storage access, indexing, and graph processing pipelines. 

http://subversion.assembla.com/svn/cogchar/trunk/src_resources_core/org/cogchar/onto/MetaDir_owl2.n3
http://subversion.assembla.com/svn/cogchar/trunk/src_resources_core/org/cogchar/onto/CircusRecipe_owl2.n3

Some thoughts about two more valuable features we would like to see in RDF Reactor, when circumstances permit.

---------------------------------------------------------------

1)  Having seen that multiple inheritance does work functionally at the class-impl level, it seems the most valuable
next feature of RDF Reactor would be to generate an exact Java interface inheritance hierarchy, implemented by
the (almost) same parallel set of Java classes it generates today.   The benefit of course would be that then the generated
Java interface types can be used algebriacally in user's java feature code.   Preferably this new code-generation mode could be
enabled by options passed to the maven plugin.  

Just in case it's not obvious what I mean:   If we have N input rdfs/owl class constructs,  then there should be N output java
interfaces (replicating *all* rdfs/owl: subClass  relations using "extends") and N java classes, where each java class
implements the corresponding interface, with almost the same name.    Perhaps to avoid clutter, the output interface and
class could share the same .java file, something like

public interface MyType extends FunType, GoodType, HappyType {

// These URI constants can be captured at the Java-interface level

    public static final URI RDFS_CLASS = new URIImpl("http://myStuff#MyType", false);

    public static final URI MYFIELD = new URIImpl("http://mystuff#myField", false);

    public static final URI[] MANAGED_URIS = {
      new URIImpl("http://mystuff/myField", false),
    };

     // Here are abstract declarations for all the fields defined directly in MyType.  Note how these get overridden in Impl below.
    public int getMyField();
    public void setMyField(int x);

    // Here the impl class is nested inside the interface.   It could now be referred to externally as MyType.Impl.
   // Only *one* of the parent impls can be extended (selected effectively at random), like today.
   // Note that we are still *inside* the MyType interface at this point, so only one .java file is needed for the whole combo
.
   pubilc class Impl extends GoodType.Impl implements MyType {

           private static final long serialVersionUID = 2271692073872392026L;
          // Same constructors as today
         // Plus we inherit all the methods from GoodType.Impl, just as we would today, and we must still reimplement
        // the methods of FunType and HappyType, just as we would today.

         // But also note that now when we implement the fields of RDFS/Owl class MyType, we need the @Override annotation:

         @Override public getMyField { // same approach as today }
         @Override public setMyField(int x) { // same approach as today }

          // Now go on and @Override impl the required methods from FunType and HappyType
   } // End of  MyType.Impl

  // Example well-known individual from idea #2 below, inserted for positional reference:

    public static final MyType  A_GOOD_INDIV  = new MyType.Impl (EMPTY_MODEL, "http://mystuff#MyType", false);

} // End of MyType (interface)

---------------------------------------------------------------

2)  (This can be pursued separately from #1, but is also shown in context of #1 example above.)

Generate static java constants for the URIs of typed individuals (i.e. well known URIs) found in the input ontology,
as fields of their target interface or class.  

Why?   Individuals can be an important part of an ontology, when they represent things like named states or flavors
(similar to "enum" patternin java).  We like to refer to java constants for these URI values , which are generated from the
same input file as the ontology type mapping code (i.e. the RDF Reactor classes).   Absent this capability, my team has
continued to use Jena's own schemagen tool in one step, together with  RDF Reactor in another step, just to get the
onto-named-constants feature.    The combination of the Jena schemagen constants with RDFReactor types works OK
at runtime, but obviously it requires more boilerplate code and build-steps than we would like.

To illustrate what we want:  If we have in our input ontology a typed individual like:

   :aGoodIndiv   rdf:type   :MyType.

...then in the generated RDFReactor code we would like to see something like this inserted into the MyType interface above:
  
    public static final MyType  A_GOOD_INDIV  = new MyType.Impl (EMPTY_MODEL, "http://mystuff#MyType", false);

where I am assuming it is possible to create/reference some kind of empty/zero model called EMPTY_MODEL.
The point here is to create a type-safe java name reference without any further assumptions.
If this approach is problematic or cumbersome on the generation side, then it would be almost as good to have
just a URI constant  like:

    public static final URI    A_GOOD_INDIV  = new URIImpl("http://mystuff#MyType");

... to at least capture the well-known name into a constant.  That is 80% of the battle, but having the nice strong type on the
constant would be a nice bonus.  I would *not* expect any property-values of  :aGoodIndiv that happen to be set in the input onto
 to get any special notice from the RDF Reactor component;  a user would still need to supply an actual runtime RDF2go
 model (possibly containing a copy of the same onto RDF) to get at those.

----------

My naive assessment of the two challenges:

It seems like #1 would only affect the output pipeline of RDFReactor (and could probably be done via the existing template-rules
mechanisms), as probably nothing new is required in the type-model lattice.

#2 requires paying attention to input individual URIs previously ignored (as far as I know), but otherwise seems pretty
straightforward.

Let me know what y'all think of these possibilities.  

peace,

Stu

[Stu Btwotwo]

Quick correction to the example from suggestion #2:

 The ontology URI of A_GOOD_INDIV should be something like    "http://mystuff#aGoodIndiv"
   

...so the code for the java constant would look more like this:
 
public static final MyType  A_GOOD_INDIV  = new MyType.Impl (EMPTY_MODEL,  "http://mystuff#aGoodIndiv", false);

[Roland Stühmer]

Hello Stue,

my time currently does not permit much, being in a new job. It would be
useful to find another research project to continue this work.

I will be on the lookout for people and please, if there are volunteers,
step forward!

Best,

Roland.

Am 17.07.2015 um 07:09 schrieb Stu Btwotwo:
> Hello RDFReactor Fans,
>
> My group is getting great results with RDF Reactor, bound using the Jena
> back end (ModelImplJena).
> We do our builds with the v5.0.1 maven plugin, which works just great.
> Thanks again for the work to create and
> maintain it! Just for fun I will mention that a few of the ontos we
> process with it now are called MetaDir and
> CircusRecipe, which represent abstractions for storage access, indexing,
> and graph processing pipelines.
>
> http://subversion.assembla.com/svn/cogchar/trunk/src_resources_core/org/cogchar/onto/MetaDir_owl2.n3
> http://subversion.assembla.com/svn/cogchar/trunk/src_resources_core/org/cogchar/onto/CircusRecipe_owl2.n3
>
> Some thoughts about two more valuable features we would like to see in
> RDF Reactor, when circumstances permit.
>
> ---------------------------------------------------------------
>
> 1) Having seen that multiple inheritance does work functionally at the
> class-impl level, it seems the most valuable
> next feature of RDF Reactor would be to generate an exact Java interface
> inheritance hierarchy, implemented by
> the (almost) same parallel set of Java classes it generates today.

[...]

> 2) (This can be pursued separately from #1, but is also shown in
> context of #1 example above.)
>
> Generate static java constants for the URIs of typed individuals (i.e.
> well known URIs) found in the input ontology,
> as fields of their target interface or class.

[...]