openRDF.org Issue Tracker

[ALI-18] OWL compiler: FileNotFoundException on Windows for FOAF

Tue, 30 Oct 2012 18:34:58 +0100 (CET)

If compiling an ontology that imports FOAF 0.1, the compilation fails on Windows, but works on Linux.

https://github.com/stain/alibaba-bug-con-person is a Maven project that involves org.openrdf.repository.object.compiler.Compiler and then unpacks the JAR to include it in a Maven module.

On Windows 7/x64 with Java 1.7 this fails with a FileNotFoundException exception. On Linux this works.

{code]
main:
    [mkdir] Created dir: C:\Users\stain\src\alibaba-bug-con-person\target\generated-sources
    [mkdir] Created dir: C:\Users\stain\src\alibaba-bug-con-person\target\generated-sources\alibaba
     [java] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
     [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
     [java] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
     [java] Exception in thread "main" org.openrdf.repository.RepositoryException: java.io.FileNotFoundException: C:\Users\stain\AppData\Local\Temp\OWLCompiler1586987051381015229\con\package-info.java (The system cannot find the path specified)
     [java] at org.openrdf.repository.object.compiler.OWLCompiler.createJar(OWLCompiler.java:363)
     [java] at org.openrdf.repository.object.compiler.Compiler.main(Compiler.java:167)
     [java] Caused by: java.io.FileNotFoundException: C:\Users\stain\AppData\Local\Temp\OWLCompiler1586987051381015229\con\package-info.java (The system cannot find the path specified)
     [java] at java.io.FileOutputStream.open(Native Method)
     [java] at java.io.FileOutputStream.<init>(Unknown Source)
     [java] at java.io.FileOutputStream.<init>(Unknown Source)
     [java] at java.io.PrintWriter.<init>(Unknown Source)
     [java] at org.openrdf.repository.object.compiler.source.JavaClassBuilder.<init>(JavaClassBuilder.java:84)
     [java] at org.openrdf.repository.object.compiler.source.JavaAnnotationBuilder.<init>(JavaAnnotationBuilder.java:73)
     [java] at org.openrdf.repository.object.compiler.source.JavaMessageBuilder.<init>(JavaMessageBuilder.java:55)
     [java] at org.openrdf.repository.object.compiler.model.RDFOntology.generatePackageInfo(RDFOntology.java:60)
     [java] at org.openrdf.repository.object.compiler.OWLCompiler.buildJavaFiles(OWLCompiler.java:471)
     [java] at org.openrdf.repository.object.compiler.OWLCompiler.compile(OWLCompiler.java:379)
     [java] at org.openrdf.repository.object.compiler.OWLCompiler.createJar(OWLCompiler.java:353)
     [java] ... 1 more
[INFO] ------------------------------------------------------------------------
{code}

On Linux:

[INFO] Executing tasks

main:
    [mkdir] Created dir: /home/stain/src/alibaba-bug-con-person/target/generated-sources
    [mkdir] Created dir: /home/stain/src/alibaba-bug-con-person/target/generated-sources/alibaba
     [java] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
     [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
     [java] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
    [unzip] Expanding: /home/stain/src/alibaba-bug-con-person/target/ontology.jar into /home/stain/src/alibaba-bug-con-person/target/generated-sources/alibaba
[INFO] Executed tasks

And the con/Person file is there:

stain@rpc268:~/src/alibaba-bug-con-person/target/generated-sources/alibaba$ ls con/Person.java -al
-rw-rw-r-- 1 stain stain 137 Sep 19 18:17 con/Person.java

Linux

[ALI-16] OWLCompiler: Handling of RDF URIs with mixed case

Wed, 6 Jun 2012 15:23:44 +0200 (CEST)

Consider the following extract from our OWL:

<rdf:Description rdf:about="#UnitSymbol">
<owl:oneOf rdf:nodeID="Xd2X26cfd7d5Xa3X12e4f66a852Xa3X-346"/>
<rdfs:label>UnitSymbol</rdfs:label>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
</rdf:Description>
<rdf:Description rdf:nodeID="Xd2X26cfd7d5Xa3X12e4f66a852Xa3X-346">
<rdf:rest rdf:nodeID="Xd2X26cfd7d5Xa3X12e4f66a852Xa3X-347"/>
<rdf:first rdf:resource="http://iec.ch/TC57/2010/CIM-schema-cim15#UnitSymbol.H/>
</rdf:Description>
<rdf:Description rdf:nodeID="Xd2X26cfd7d5Xa3X12e4f66a852Xa3X-347">
<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
<rdf:first rdf:resource="http://iec.ch/TC57/2010/CIM-schema-cim15#UnitSymbol.h"/>
</rdf:Description>

<rdf:Description rdf:about="http://iec.ch/TC57/2010/CIM-schema-cim15#UnitSymbol.H">
<rdfs:label>H</rdfs:label>
</rdf:Description>
<rdf:Description rdf:about="http://iec.ch/TC57/2010/CIM-schema-cim15#UnitSymbol.h">
<rdfs:label>h</rdfs:label>
</rdf:Description>

Using the OWLCompiler to generate Java sources, this generates a Java interface that does not compile (with the Java compiler) - because of duplicate field definitions. According to my understanding, RDF URIs are case-sensitive, so the construct above seems valid to me.

I've had a look at the source code, and the problem originates from the method org.openrdf.repository.object.compiler.model.RDFClass#constants(org.openrdf.repository.object.compiler.source.JavaMessageBuilder)

One solution could be to remove the toUpperCase() in the method referenced above, but I do not know if that can have other implications.

[ALI-15] OWLCompiler: Ability to disable the use of NamespacePrefixService

Thu, 22 Mar 2012 16:17:50 +0100 (CET)

I am sitting behind a proxy server. This makes the NamespacePrefixService fail if I do not set the JVM http proxy settings.
It would be nice if it was possible to set a property on OWLCompiler that disables the use of NamespacePrefixService.

[ALI-14] remove and add one statement in one transcation

Thu, 22 Mar 2012 16:20:32 +0100 (CET)

If a statement is removed and added in the same transaction, then this statement is twice in the MemoryStore until the transaction is committed.
After commit everything is correct.

        Repository myRepository = new OptimisticRepository(new MemoryStore());

        myRepository.initialize();
        ValueFactory f = myRepository.getValueFactory();
        RepositoryConnection con = myRepository.getConnection();
        con.setAutoCommit(false);

        Statement s = f.createStatement(f.createURI("http://e.org/people/alice"), f.createURI("http://e.org/ontology/name"), f.createLiteral("Alice"));
        con.add(s);
        con.commit();

        con.remove(s);
        con.add(s);

        System.out.println("s twice: " + con.getStatements(null, null, null, true).asList());

        con.commit();

        System.out.println("s once: " + con.getStatements(null, null, null, true).asList());

[ALI-13] Local file loaded ontologies are not recognised as imports for other ontologies

Wed, 29 Feb 2012 21:11:40 +0100 (CET)

If I download all of the ontologies and then try to compile them using a list of the files submitted to org.openrdf.repository.object.compiler.Compiler.main, the org.openrdf.repository.object.compiler.OntologyLoader will still try to fetch the ontologies, as they have been loaded from file: URL's, and not their http: equivalents.

The bug may be fixed by modifying the following line in OntologyLoader.followImports():

    if (!model.contains(null, null, null, uri)) {

so that it says:

    if (!model.contains(null, null, null, uri) && !model.contains(uri, RDF.TYPE, OWL.ONTOLOGY)) {

With that modification, the locally loaded ontology, assuming the base URI was set correctly, will be recognised as a copy of the resource, and the URL will not attempt to be fetched.

It would be nice in future if Alibaba supported something like LocationMapper from Jena or OWLOntologyIRIMapper from OWLAPI, but this change will fix my immediate issues. I am trying to update the SCUFL2 library that was previously using Elmo to use Alibaba.

My test code is:

        List<String> argsList = new ArrayList<String>();

        argsList.add("-j");
        argsList.add("target/scufl2-ontology.jar");
        argsList.add("src/test/resources/skos-owl1-dl.rdf");
        argsList.add("src/test/resources/dcterms_od.rdf");
        argsList.add("src/test/resources/dcam.rdf");
        argsList.add("src/test/resources/scufl2.rdf");

        // run the compiler using the arguments given above
        org.openrdf.repository.object.compiler.Compiler.main(argsList.toArray(new String[argsList.size()]));

Right now it runs into issues trying to interpret one of the URLs as an RDF/XML document, which is another bug, but one that may not be as easy to fix as this one.

[ALI-12] Object repository compiler generates concepts with non-symmetric accessors for collection properties

Fri, 26 Aug 2011 15:07:02 +0200 (CEST)

The object repository compiler generates getter/setter with different generics for a collection property. The setter is generated with a generics wildcard, but the getter is not. I think the correct behavior should be to use a generics wildcard in both accessors.

An example:
public interface NameType {
   Set<Name> getNameType_Names();
   void setNameType_Names(Set<? extends Name> NameType_Names);
}

I think this should be:
public interface NameType {
   Set<? extends Name> getNameType_Names();
   void setNameType_Names(Set<? extends Name> NameType_Names);
}

[ALI-11] Compilation of Java-Classes fails if the ontology specifies a property which is inferred by a subclass and restricted

Wed, 10 Aug 2011 20:21:06 +0200 (CEST)

The Problem is easy to understand with the following example. The Code of the OWL-file is attached.

I think, the problem is in the restriction of the property for AlevelFormation Entity. In my example the entity Formation is connected via hasPart to other Formation or VehicleThing. The ALevelFormation, which is a Formation restricts the hasPart property in that way, that only Object of the Type BLevelFormation can be addressed. The compiler founds a Set BLevelFormation for getHasPart in the generated interface ALevelFormation because of the depth of inheritance ALevelFormation should specify V

/var/folders/l5/4z_54rs55dx51dslmss40qpm0000gn/T/OWLCompiler1701491496037452730/testOnto/ALevelFormation.java:9: getTestOntoHasPart() in testOnto.ALevelFormation clashes with getTestOntoHasPart() in testOnto.Formation; attempting to use incompatible return type
found : java.util.Set<testOnto.BLevelFormation>
required: java.util.Set<testOnto.FormationOrVehicleThing>
Set<BLevelFormation> getTestOntoHasPart();

Here is an Example file:

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [
    <!ENTITY owl "http://www.w3.org/2002/07/owl#" >
    <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
    <!ENTITY owl2xml "http://www.w3.org/2006/12/owl2-xml#" >
    <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
    <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
    <!ENTITY testOnto "http://www.uni-paderborn.de/ontologies/2011/7/testOnto.owl#" >
]>

<rdf:RDF xmlns="http://www.uni-paderborn.de/ontologies/2011/7/testOnto.owl#"
     xml:base="http://www.uni-paderborn.de/ontologies/2011/7/testOnto.owl"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:owl2xml="http://www.w3.org/2006/12/owl2-xml#"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:testOnto="http://www.uni-paderborn.de/ontologies/2011/7/testOnto.owl#">
    <owl:Ontology rdf:about="">
        <rdfs:comment
            >Just a test ontology</rdfs:comment>
    </owl:Ontology>


    



    

    <owl:ObjectProperty rdf:about="#hasPart">
        <rdfs:domain rdf:resource="#Formation"/>
        <rdfs:range>
            <owl:Class>
                <owl:unionOf rdf:parseType="Collection">
                    <rdf:Description rdf:about="#Formation"/>
                    <rdf:Description rdf:about="#VehicleThing"/>
                </owl:unionOf>
            </owl:Class>
        </rdfs:range>
    </owl:ObjectProperty>


    



    

    <owl:Class rdf:about="#ALevelFormation">
        <rdfs:subClassOf rdf:resource="#FBFormation"/>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="#hasPart"/>
                <owl:allValuesFrom rdf:resource="#BLevelFormation"/>
            </owl:Restriction>
        </rdfs:subClassOf>
        <owl:disjointWith rdf:resource="#BLevelFormation"/>
    </owl:Class>


    

    <owl:Class rdf:about="#BLevelFormation">
        <rdfs:subClassOf rdf:resource="#FBFormation"/>
    </owl:Class>


    

    <owl:Class rdf:about="#FBFormation">
        <rdfs:subClassOf rdf:resource="#Formation"/>
    </owl:Class>


    

    <owl:Class rdf:about="#Formation">
        <rdfs:subClassOf rdf:resource="#SARThing"/>
    </owl:Class>


    

    <owl:Class rdf:about="#SARThing"/>


    

    <owl:Class rdf:about="#VehicleThing">
        <rdfs:subClassOf rdf:resource="#SARThing"/>
    </owl:Class>
</rdf:RDF>

[ALI-10] create and remove a Statement in the same transaction does not work

Tue, 17 May 2011 15:15:35 +0200 (CEST)

If I try to remove a Statement which I created in the same transaction, then the Statement is still there.
I tried it with MemoryStore and NativeStore.

Repository myRepository = new OptimisticRepository(new MemoryStore());
// Repository myRepository = new OptimisticRepository(new NativeStore(new File("store")));
myRepository.initialize();
ValueFactory f = myRepository.getValueFactory();
RepositoryConnection con = myRepository.getConnection();
con.setAutoCommit(false);

Statement s = f.createStatement(f.createURI("http://example.org/people/alice"), f.createURI("http://example.org/ontology/name"), f.createLiteral("Alice"));
                con.add(s);

                con.remove(s);

RepositoryResult<Statement> stats = con.getStatements(null, null, null, true);
System.out.println("should be empty: " + stats.asList());

                con.close();
                myRepository.shutDown();

[ALI-9] Be able to use classes as argument for @sparql annotated methods

Fri, 11 Mar 2011 17:34:35 +0100 (CET)

It would be nice to be able to write something like:

@sparql("SELECT ?entity WHERE {?this <a:ref> ?entity . ?entity a ?type}") <T extends BaseType> Set<T> getReferencedEntities(@name("type") Class<T> clazz);

Where the query generator would deduce the possible type(s) from the @iri annotation(s) of the clazz.

I currently write such queries as (with the disadvantages that I have to resolve @iri annotations on a class myself, and that I have to caset the result):
@sparql("SELECT ?entity WHERE {?this <a:ref> ?entity . ?entity a ?type}") Set<? extends BaseType> getReferencedEntities(@name("type") String type);

[ALI-6] Refactoring of OWLCompiler to facilitate creating a Maven plugin to compile OWL ontologies

Sun, 10 Oct 2010 02:18:09 +0200 (CEST)

I have created a simple Maven plugin that compiles OWL ontologies using OWLCompiler. The plugin is working, and is usable, but the current design of OWLCompiler is all-or-nothing, which doesn't allow me to create a proper Maven plugin. I will try to explain:

Currently OWLCompiler has only one functional public method: compile; that performs everything:
- Generating Java sources
- Generating resources (that ends up in the META-INF folder of the resulting jar-file)
- Compiling the generated Java sources
- Creating the jar-file containing generated Java sources, compiled Java classes, generated resources and the original OWL-file(s)

My Maven plugin currently contains only one goal (compile), that is typically bound to the package phase of the Maven default lifecycle (http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html). This has numerous drawbacks, i.e.:
- IDE integration; an OWL module is unable to co-exist in the same project as a Java module with compile-time dependency to the generated OWL Java classes/sources. Any proper Maven to Java IDE integration will typically run the Maven default lifecycle up to the generate-sources/process-resources phase prior to module/project import. This allows for any generated source to be generated, and the generated sources to be added to the source path of the project/module.
- Maven artifact conformance; to include pom.xml and pom.properties in the jar-file (as any Maven built module should have) of my OWL module, I have to re-pack the jar-file after OWL-compile.
- "Re-inventing the wheel"; in Maven you have plugins for common tasks like compiling Java Source (maven-compiler-plugin) and for creating jar-files (maven-jar-plugin). These may be configured in Maven for a dedicated purpose, and I want to use these plugins to compile the generated sources and to create the jar-file.

While keeping the compile-method for backwards-compatibility, and for those not using Maven, I think it should be possible to make steps in the compile process publicly available (outside the OWLCompiler class). Referring to the Maven default lifecycle, I would like to create (at least) two goals in my plugin:
1) "generate-sources" (typically bound to the generate-sources phase); Generate the Java source code for the OWL ontologies. I would like to set the target directory for the generated sources.
2) "generate-resources" (typically bound to the generate-resources phase); Generate the resources (files) for the OWL ontologies (that will end up in the META-INF folder of the resulting jar-file). I would like to set the target directory for the generated resources.

I have looked into the source code, and I think the changes that will have to be done is quite simple, but I would prefer that someone with depth knowledge of the codebase reviews my suggestion before I eventually move forward and suggest a patch.

I would also be happy to share the Maven plugin with the community. Suggestions on how to do this is appreciated.

[ALI-2] ObjectCompileException when a namespace prefix contains a period

Sat, 12 Jun 2010 21:35:57 +0200 (CEST)

The FOAF ontology (http://xmlns.com/foaf/spec/20100101.rdf) compiles as expected but the Compiler throws the following exception when a period '.' is inserted in a namespace prefix, for instance by replacing the "foaf" prefix with "fo.af".

Exception in thread "main" org.openrdf.repository.object.exceptions.ObjectCompileException: Could not compile
at org.openrdf.repository.object.compiler.source.JavaCompiler.compile(JavaCompiler.java:74)
at org.openrdf.repository.object.compiler.OWLCompiler.compileConcepts(OWLCompiler.java:473)
at org.openrdf.repository.object.compiler.OWLCompiler.compile(OWLCompiler.java:301)
at org.openrdf.repository.object.compiler.Compiler.main(Compiler.java:151)

[ALI-1] NullPointerException when creating ObjectRepository on non-persistent MemoryStore

Sat, 3 Apr 2010 17:51:57 +0200 (CEST)

The following Java code:
        MemoryStore sail = new MemoryStore();
        SailRepository repo = new SailRepository(new ForwardChainingRDFSInferencer(sail));
        ObjectRepositoryFactory factory = new ObjectRepositoryFactory();
        ObjectRepository objectRepo = factory.createRepository(repo);
        objectRepo.initialize();

Yields the following exception: java.lang.NullPointerException
at org.openrdf.repository.object.ObjectRepository.incrementRevision(ObjectRepository.java:500)
at org.openrdf.repository.object.ObjectRepository.compileSchema(ObjectRepository.java:427)
at org.openrdf.repository.object.ObjectRepository.compile(ObjectRepository.java:361)
at org.openrdf.repository.object.ObjectRepository.init(ObjectRepository.java:248)
at org.openrdf.repository.object.ObjectRepository.initialize(ObjectRepository.java:209)
....