Roundtripping typed literals with RDF import/export

Using still 3.5, I noticed that if I use importRDFSnippet and post a graph that includes a typed triple, e.g., xsd:dateTime, and then export the same using the /rdf/cypheronrdf endpoint, the returned triple lacks the datatype annotation.

Is that to be expected? Is this behavior changed in 4.0?

Hi @mdw00d, I've just run this simple test and datatypes seems to be consistent on export:

Here's on 3.5:

call semantics.importRDFSnippet('

@prefix : <> .
@prefix foaf: <> .
@prefix xsd: <> .

<issue227> a :SecurityIssue ;
    :reportedBy <user6> ; 
    :reportedOn "2012-12-31T23:57:00"^^xsd:dateTime ;
    :reproducedOn "2012-12-31"^^xsd:date ; 
    :related <issue4> .


When exported via describe:

:GET /rdf/describe/uri/


@prefix rdf: <> .
@prefix neovoc: <neo4j://vocabulary#> .
@prefix neoind: <neo4j://individuals#> .

<> a <>;
  <> <>;
  <> <>;
  <> "2012-12-31T23:57:00"^^<>;
  <> "2012-12-31"^^<> .

Similarly on 4.0, the same RDF snippet imported via call n10s.rdf.import.inline when exported

:GET http://localhost:7474/rdf/conn-study/describe/


@prefix ns0: <> .
@prefix rdf: <> .

<> a ns0:SecurityIssue;
  ns0:related <>;
  ns0:reportedBy <>;
  ns0:reportedOn "2012-12-31T23:57:00"^^<>;
  ns0:reproducedOn "2012-12-31"^^<> .

Make sure the format is the one above for both date and dateTime, otherwise the value will be persisted as a string.

Hope this helps,


So looking at this more closely, it appears the problem is with dateTime values with timezone info.

Importing Turtle with a timezone aware time value, such as the following, causes the dateTime value to be construed as a string.

@prefix dcterms: <> .
@prefix rdfs: <> .
@prefix xsd: <> .
@prefix ex: <> .

<urn:guid:246f5a94b4d111eabb02d4258b8e4db9> a ex:Example ;
    rdfs:label "This is a string" ;
    dcterms:modified "2020-06-22T21:41:34.066344+00:00"^^xsd:dateTime ;

Looking at the neo4j 3.5 file, method getDataType, I see that it looks to see if the literal is an instance of LocalDateTime, which is a non timezone aware type. Didn't study the code carefully enough to see if that is in fact the root cause, but might be the problem.

Yes, we only try to parse the date with the default format and if it does not parse then we treat it as a string

I guess we could use a more generic format (or maybe try a couple of them) in order to accommodate both millisecs and timezones. Could you please add it as an issue in GitHub?