xsd:dateTime datatype cannot be verified


(Nolan Nichols) #1

I'm seeing the following error when trying to load a dataset with datetime information:

ERROR 2018-11-26 10:47:41,971 [stardog-user-175] com.complexible.stardog.protocols.http.server.StardogHttpServiceLoader:accept(232): An exception was handled by the server: '2018-10-21T22:45:39' was not recognised, and could not be verified, with datatype xsd:dateTime [L136]

I generally have good luck using the redland rapper library to validate RDF. It doesn't seem to have any issues with the values of 2018-10-21T22:45:39, but it looks like this isn't valid in stardog.

One thing to note is that I generated the turtle version of this document based on json-ld (using the playground)... When I tried to load the jsonld directly, I received a similar issue:

stardog data add grex ~/Downloads/prov.jsonld
Adding data from file: /Users/ubuntu/Downloads/prov.jsonld
'2018-10-21T22:45:39Z' was not recognised, and could not be verified, with datatype xsd:dateTime [L1]

Do you have any suggestions for how to resolve this issue?


(stephen) #2

Hi,

I am actually unable to reproduce this issue with the latest Stardog.

  1. Which version are you seeing this error with?
  2. Can you provide a minimal JSON-LD or ttl file that I can use to reproduce?

(Nolan Nichols) #3

This is with stardog 6.0

{
  "@context": {
    "prov": "http://www.w3.org/ns/prov",
    "regdatetime": {
      "@id": "prov:generatedAtTime",
      "@type": "xsd:dateTime"
    }},
  "regdatetime": "2018-10-21T22:45:39Z"

}

(Nolan Nichols) #4

Any luck replicating this issue?


(stephen) #5

Hi Nolan,

Apologies in the delay here. I was able to reproduce this issue on a database where the strict.parsing property is set to true (the default, I believe).

Setting it to false DOES make this problem go away...by no longer attempting to validate the value as a dateTime. I'm looking further into why it doesn't consider it valid.


(stephen) #6

Actually I can see exactly why it's not valid. Our JSON-LD parser is not using the XSD namespace and as such thinks that "xsd:dateTime" is the datatype instead of "http://www.w3.org/2001/XMLSchema#dateTime."

I will open up a ticket to address this behavior, but in the meantime you can expand the XSD datatypes to work around this.


(Nolan Nichols) #7

Thanks @stephen. I can confirm that disabling strict parsing allows me to upload this triple with the timestamp. Although it didn't look like I could do this without first dropping the db.

One thing to note is that I'm also seeing this in other RDF serializations, for example there is the same issue below, so probably not just the json-ld parser.

$ cat test.ttl
_:b0 <http://www.w3.org/ns/prov#generatedAtTime> "2018-10-21T22:45:39Z"^^<xsd:dateTime> .

$ stardog data add grex test.ttl
Adding data from file: test.ttl
'2018-10-21T22:45:39Z' was not recognised, and could not be verified, with datatype xsd:dateTime [L1]

(Evren Sirin) #8

Hi Nolan,

The angle brackets in Turtle is meant for absolute IRIs whereas here you are trying to use a prefixed name so you don't need the brackets. If you change the literal to "2018-10-21T22:45:39Z"^^xsd:dateTime it should work.

Best,
Evren


(Nolan Nichols) #9

Ah, so this is looking like my own mistake using jsonld and not including the xsd namespace. If I include the xsd namespace then this will work:

{
  "@context": {
    "prov": "http://www.w3.org/ns/prov",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "regdatetime": {
      "@id": "prov:generatedAtTime",
      "@type": "xsd:dateTime"
    }},
  "regdatetime": "2018-10-21T22:45:39Z"
}

The brackets around the xsd:dateTime were introduced by the translation from jsonld to turtle when the namespace is missing.

Once corrected, this seems to work - although it may be nice if there were default namespaces that were recognized.

@evren thanks for catching that!


(system) #10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.