Roundtripping typed literals with RDF import/export

[mdw00d]

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?

[jesus_barrasa]

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 : <http://www.w3.org/2012/12/rdf-val/SOTA-ex#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

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

','Turtle')

When exported via describe:

:GET /rdf/describe/uri/http%3A%2F%2Fneo4j.com%2Fbase%2Fissue227

returns:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix neovoc: <neo4j://vocabulary#> .
@prefix neoind: <neo4j://individuals#> .


<http://neo4j.com/base/issue227> a <http://www.w3.org/2012/12/rdf-val/SOTA-ex#SecurityIssue>;
  <http://www.w3.org/2012/12/rdf-val/SOTA-ex#related> <http://neo4j.com/base/issue4>;
  <http://www.w3.org/2012/12/rdf-val/SOTA-ex#reportedBy> <http://neo4j.com/base/user6>;
  <http://www.w3.org/2012/12/rdf-val/SOTA-ex#reportedOn> "2012-12-31T23:57:00"^^<http://www.w3.org/2001/XMLSchema#dateTime>;
  <http://www.w3.org/2012/12/rdf-val/SOTA-ex#reproducedOn> "2012-12-31"^^<http://www.w3.org/2001/XMLSchema#date> .

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/http%3A%2F%2Fneo4j.com%2Fbase%2Fissue227

returns:

@prefix ns0: <http://www.w3.org/2012/12/rdf-val/SOTA-ex#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://neo4j.com/base/issue227> a ns0:SecurityIssue;
  ns0:related <http://neo4j.com/base/issue4>;
  ns0:reportedBy <http://neo4j.com/base/user6>;
  ns0:reportedOn "2012-12-31T23:57:00"^^<http://www.w3.org/2001/XMLSchema#dateTime>;
  ns0:reproducedOn "2012-12-31"^^<http://www.w3.org/2001/XMLSchema#date> .

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,

JB.

[mdw00d]

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: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex: <http://example.com/> .

<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 RDFImport.java, 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.

[jesus_barrasa]

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

github.com

neo4j-labs/neosemantics/blob/2b7ccc2c1b1a7cc96bfd5e97903db9f57a9ca8b9/src/main/java/n10s/RDFToLPGSta...

    return null;
  }
} else if (typeMapsToLongType(datatype)) {
  return object.longValue();
} else if (typeMapsToDouble(datatype)) {
  return object.doubleValue();
} else if (datatype.equals(XMLSchema.BOOLEAN)) {
  return object.booleanValue();
} else if (datatype.equals(XMLSchema.DATETIME)) {
  try {
    return LocalDateTime.parse(object.stringValue());
  } catch (DateTimeParseException e) {
    //if date cannot be parsed we return string value
    return object.stringValue();
  }
} else if (datatype.equals(XMLSchema.DATE)) {
  try {
    return LocalDate.parse(object.stringValue());
  } catch (DateTimeParseException e) {
    //if date cannot be parsed we return string value
    return object.stringValue();

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?

Thanks!

JB.