Multiple Inheritance in generated Java classes/interfaces

[Stu Btwotwo]

Hello Group,

RDF-Reactor is a great tool and I am very grateful for it!

From this paper I gather that RDFReactor supported multiple inheritance (in the
Java code generation) at one time.

https://f85aee65e326ec9b1bafadff9f35faba133e1f56.googledrive.com/host/0B7VODTi7FQL1a2Fzd2Y4YVkyblU/2006/05-RDFReactor-JUC2006.pdf

I am currently using the maven plugin (version 4.8.3) to generate Java classes from
some relatively simple ontologies saved from Protege 4.3.  The ontologies
use owl:Class, rdfs:subClassOf, rdfs:domain, rdfs:range, and are saved in turtle/n3 format.
The generation works pretty well for the single-inheritance case, but I have not
successfully used multiple inheritance.  I think my result when I tried it
was basically that only one parent rdfs:class was used in the generation of each Java
class, and other parents were ignored;  I could re-verify that and supply more details,
if it's not a well known issue (but I'm guessing it is!).    

Is code generation respecting multiple inheritance at all possible with current versions of the
libraries? 

It looks like there may be features in the generator source code that are not
easily accessed from the maven plugin, but I have not had a chance to delve into them.
Is that where I should be looking?  

peace,

Stu

[Roland Stühmer]

Stu Btwotwo wrote:
> I am currently using the maven plugin (version 4.8.3) to generate
> Java classes from some relatively simple ontologies saved from
> Protege 4.3. The ontologies use owl:Class, rdfs:subClassOf,
> rdfs:domain, rdfs:range, and are saved in turtle/n3 format.

There is a 5.0.1 available from Maven Central.
http://mvnrepository.com/artifact/org.semweb4j I suggest using the
newest one.

> The generation works pretty well for the single-inheritance case, but
> I have not successfully used multiple inheritance. I think my result
> when I tried it was basically that only one parent rdfs:class was
> used in the generation of each Java class, and other parents were
> ignored; I could re-verify that and supply more details, if it's not
> a well known issue (but I'm guessing it is!).

I think it's not! :) (I am the maintainer but not the original author of
the code.)

Please try one last time with the newest plugin and then send your test
case (turtle file) here: https://code.google.com/p/semweb4j/issues/list

> Is code generation respecting multiple inheritance at all possible
> with current versions of the libraries?

It should be possible! Multiple inheritance is "resolved" in Java by
using only one parent as the extended class whereas other inherited
methods are copied into the child class to simulate the behaviour of
having inherited them.

> It looks like there may be features in the generator source code
> that are not easily accessed from the maven plugin, but I have not
> had a chance to delve into them. Is that where I should be looking?
>

I think inheritance cannot be configured, it should work using the
plugin in any setting.

Best!

Roland.

[Stu Btwotwo]

Hi Roland,

Thank you very much!  This info was a big help.  Here is what I have found:

Multiple inheritance does indeed work (except for a problem with owl:maxCardinality, see below),
using both current version 5.0.1 and earlier version 4.8.3 (via the maven plugin, in both cases).
Whatever problem was in my way with it before is not there anymore, and that was probably some
misconfiguration or missed observations on my part.  So, for the most part we are now in the
clear on this topic; hooray!  I apologize for not testing more thoroughly before my first posting
to the list;   I just had it in my mind somehow that this feature was broken, but I was wrong.
[I have not yet had a chance to actually *run* any Java application code using the multiple inheritance
feature, but I don't expect that to be an issue.  If I find any problems, I will report them separately].
Thanks again for your clear and accurate description of the actual feature status. :-)

I did find one apparent RDFReactor code-generation bug related to multiple inheritance, however.  
We often use  owl:maxCardinality (with a value of 1) to mark the properties that should have no more
than one value.  In general, this marking is correctly picked up by RDFReactor, and used to make
the method signatures appropriate for a single value (rather than the default collection-oriented
signatures).   This feature appears to *almost* work properly in combination with multiple
inheritance.   The generated method signatures are as expected.  However, the generated code (in
the Java classes with extra patched-up fields+methods) is missing an import statement for the java
class:

org.ontoware.rdfreactor.runtime.CardinalityException.

...and this causes the generated Java code to not compile.
This problem occurs with both Semweb4j 5.0.1 and 4.8.3.

I set up a test project using Semweb4j 5.0.1.   A static snapshot of the whole project, in a state
where it fails to compile, can be seen here:

https://www.assembla.com/code/friendularity/subversion/nodes/822/trunk/maven/org.friendularity.demo.sweb4j

You will see that it generates code from two separate variants of a single toy ontology.

The full ontology is called PhysicsTest_owl2.n3.  It has lots of classes (about 40)
and uses lots of multiple inheritance, but is careful to avoid using owl:maxCardinality in
places where it could apply to a property that is inherited indirectly.  The code generated
from this ontology compiles OK.  I locally generate Javadoc from those classes to make it
easier to verify that all the fields are bound to all the classes I expect, and they are!
(Others who wish to experiment with multiple inheritance may want to look at this file and
the output code for themselves). 

Then the owl:maxCardinality exception import problem is demonstrated by a second, smaller ontology
called PhysicsTest_brokenCard_owl2.n3.  Here is a snapshot of the ontology file in its broken state:

https://www.assembla.com/code/friendularity/subversion/nodes/822/trunk/maven/org.friendularity.demo.sweb4j/src/test/resources/schemas/PhysicsTest_brokenCard_owl2.n3

The code generation is broken by the assertion of owl:maxCardinality 1   on the two properties
     :hasElementaryCharge
and  :hasRestMassInGrams

I get 12 Java compile errors total, because the generated code for CompositeParticle.java,
Lepton.java and Positron.java are all missing the import statement

import org.ontoware.rdfreactor.runtime.CardinalityException;

...which in contrast is correctly included in Electron.java (because it is the domain for
:hasSimpleSingleValuedDataProp), so we get no compile errors in Electron.java.

This looks like a simple problem in the RDFReactor template rules that is only exposed under
the conditions described above and in the comments in the PhysicsTest_brokenCard_owl2.n3 ontology.

I am using JDK 1.7-update 72, Maven 3.0.5, on Windows 7(x64).  The ontologies were edited using
Protege 4.3.0.

If the relevant template rule can be fixed in a future Semweb4J release, that would be great.
I will be happy to re-enter this information into a bug report if you think that is a good idea.

peace,

Stu

[Max Völkel, Calpano]

Just a quick remark, while that bug exists: I usually fix such errors in Eclipse by calling the Source > Organize Imports feature. That adds all required imports and removes all unnecessary ones. Just a work-around, I know.

--
You received this message because you are subscribed to the Google Groups "RDF2Go and RDFReactor (part of semweb4j)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semweb4j+u...@googlegroups.com.
To post to this group, send email to semw...@googlegroups.com.
Visit this group at http://groups.google.com/group/semweb4j.
For more options, visit https://groups.google.com/d/optout.

--

Calpano, ein Projekt der IT Beratung Dr. Max Völkel

Jollystr. 69, D-76137 Karlsruhe, Deutschland.

Einzelunternehmen. Unternehmenssitz ist 76137 Karlsruhe. Inhaber ist Herr Max Völkel. 

Email: max.v...@calpano.com

Consulting | Web Technologies | Lean Startup | New Product: DenkWerkZeug.com