java.lang.ArrayStoreException: arraycopy: element type mismatch

Neo4j 4.0.4
neosemantics 4.0.0.1

Importing dpedia following this approach:

https://gist.github.com/kuzeko/7ce71c6088c866b0639c50cf9504869a

I get the following error in neo4-j-server/log/neo4j.log :

java.lang.ArrayStoreException: arraycopy: element type mismatch: can not cast one of the elements of java.lang.Object[] to the type of the destination array, java.lang.String
        at java.base/java.lang.System.arraycopy(Native Method)
        at java.base/java.util.ArrayList.toArray(ArrayList.java:432)
        at org.neo4j.internal.helpers.collection.Iterables.asArray(Iterables.java:188)
        at n10s.RDFToLPGStatementProcessor.toPropertyValue(RDFToLPGStatementProcessor.java:456)
        at n10s.rdf.load.DirectStatementLoader.lambda$runPartialTx$2(DirectStatementLoader.java:73)
        at java.base/java.util.HashMap.forEach(HashMap.java:1336)
        at n10s.rdf.load.DirectStatementLoader.runPartialTx(DirectStatementLoader.java:69)
        at n10s.rdf.load.DirectStatementLoader.periodicOperation(DirectStatementLoader.java:187)
        at n10s.RDFToLPGStatementProcessor.handleStatement(RDFToLPGStatementProcessor.java:416)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.reportStatement(TurtleParser.java:1123)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseObject(TurtleParser.java:463)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseObjectList(TurtleParser.java:390)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parsePredicateObjectList(TurtleParser.java:363)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseTriples(TurtleParser.java:350)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseStatement(TurtleParser.java:217)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parse(TurtleParser.java:179)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parse(TurtleParser.java:131)
        at n10s.CommonProcedures.instantiateAndKickOffParser(CommonProcedures.java:122)
        at n10s.CommonProcedures.parseRDFPayloadOrFromUrl(CommonProcedures.java:110)
        at n10s.rdf.RDFProcedures.doImport(RDFProcedures.java:77)
        at n10s.rdf.load.RDFLoadProcedures.fetch(RDFLoadProcedures.java:19)

followed by

org.neo4j.graphdb.NotInTransactionException: The transaction has been closed.
        at org.neo4j.kernel.impl.coreapi.TransactionImpl.checkInTransaction(TransactionImpl.java:667)
        at org.neo4j.kernel.impl.coreapi.TransactionImpl.kernelTransaction(TransactionImpl.java:548)
        at org.neo4j.kernel.impl.core.NodeEntity.getProperty(NodeEntity.java:304)
        at n10s.rdf.load.DirectStatementLoader.lambda$runPartialTx$2(DirectStatementLoader.java:71)
        at java.base/java.util.HashMap.forEach(HashMap.java:1336)
        at n10s.rdf.load.DirectStatementLoader.runPartialTx(DirectStatementLoader.java:69)
        at n10s.rdf.load.DirectStatementLoader.periodicOperation(DirectStatementLoader.java:187)
        at n10s.RDFToLPGStatementProcessor.handleStatement(RDFToLPGStatementProcessor.java:416)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.reportStatement(TurtleParser.java:1123)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseObject(TurtleParser.java:463)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseObjectList(TurtleParser.java:390)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parsePredicateObjectList(TurtleParser.java:363)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseTriples(TurtleParser.java:350)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parseStatement(TurtleParser.java:217)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parse(TurtleParser.java:179)
        at org.eclipse.rdf4j.rio.turtle.TurtleParser.parse(TurtleParser.java:131)
        at n10s.CommonProcedures.instantiateAndKickOffParser(CommonProcedures.java:122)

Issue Analytics

State:
Created 3 years ago
Comments:9

Top GitHub Comments

1reaction

kuzekocommented, Jun 5, 2020

I see. I was not familiar with the custom data type treatment in neosemantics.

I think I did not explain clearly my options 2 and 3.

Option 3 would be like to have keepCustomDataTypes: true + something like checkConsistency : false (making up option names) : in the end these two option together will end in an array of strings anyway. Consider the example in the manual https://neo4j.com/docs/labs/nsmntx/current/import/#handling-custom-data-types#d0e1095 containing

assume all values are for the same property like this

@prefix ex: <http://example.com/> .

ex:Mercedes
    rdf:type ex:Car ;
    ex:price "10000"^^ex:EUR ;
    ex:price "300"^^ex:HP ;
    ex:price "red"^^ex:Color .

the output would be an array like this

[  "10000^^ns0__EUR" ,  "300^^ns0__HP" , "red^^ns0__Color" ]

and data-cleaning would take place later, e.g., I have a conversion formula to move from 300^^ns0__HP to some amount of ns0__EUR same for red

if we set checkConsistency : true we have an import error.

The second option instead was to drop the datatype, so to keep only what you describe as value for the properties. Yet, in this case, since we have red in the mix, we expect an import error.

W.r.t. “let the first decide the type” I understand the issue, but this is already happening when you have that n10s default behavior is to keep only one value for literal properties and it will be the last one read in the triples parsed. no?

Finally, a more “extreme” option: why not having multi-valued properties be translated to a value node and the edge be the type? I think this would be similar to materializing a “blank” node in RDF.

1reaction

jbarrasacommented, Jun 4, 2020

I think I got it. The problem is that when storing multi-valued RDF properties in an array { handleMultival: "ARRAY" } Neosemantics expects all values to be consistent in datatype. Now, there seem to be violations of that in the dbpedia. Here’s an example:

<http://dbpedia.org/resource/%22No_Flashlight%22:_Songs_of_the_Fulfilled_Night> <http://dbpedia.org/property/totalLength> "2271.0"^^<http://dbpedia.org/datatype/second> .
<http://dbpedia.org/resource/%22No_Flashlight%22:_Songs_of_the_Fulfilled_Night> <http://dbpedia.org/property/totalLength> "45.75"^^<http://www.w3.org/2001/XMLSchema#double> .

You can see that the totalLength property has one value that is a xsd:double and another one that is a dbpedia:second.

Now the question is: Should we accept “anarchy” and have multi-datatype arrays? (which in my opinion means a practically unusable graph?) Or should we impose certain minimal data quality validations on import? What do you think, @kuzeko ?

There was a second problem which was the fact that when the partial commits (separate transactions) choke, they seem to fail silently and the import process keeps going on and eventually terminates completely unaware of the fact that some/all partial commits failed.

To that one, I think probably a new config param to specify whether to stop the import on the first failure or just continue and log would probably be the right thing to do? Again, what’s your opinion on this one?

Thanks a lot for uncovering these issues with your testing. Really valuable 😃

Cheers,

JB.