STRDT not working on INSERT

Support Bug
1

While manipulating data in a named graph I discovered that changing the type of a literal with STRDT is not working correctly.
Given the following data:

INSERT DATA {
    GRAPH <http://www.foo.org/test> {
        :i :p "123"^^xsd:integer . 
        :p rdfs:range xsd:integer
    }
}

The following DELETE/INSERT combination should switch the range as well as all assertions into xsd:long. This fails for the assertions:

DELETE {
graph <http://www.foo.org/test> {
        ?s ?p ?o.
        ?p rdfs:range ?r }
}
INSERT { graph <http://www.foo.org/test> {
        ?s ?p ?o2.
        ?p rdfs:range xsd:long }
}
WHERE {
    graph <http://www.foo.org/test> {
        {
            SELECT ?p {
                ?x ?p ?y.
                FILTER(datatype(?y) = xsd:integer)
                FILTER (?y > 10)
            }
        }
        ?s ?p ?o .
        ?p rdfs:range ?r
        BIND(STRDT(STR(?o), xsd:long) AS ?o2)
        }
}
2

Hi,

Try using xsd:long as a casting function:

BIND(xsd:long(STR(?o)) AS ?o2)
3

Ok, I replaced the BIND clause with the one you provided. Unfortunately I get the following on execution:
Failed to run query: 00UOE2. There was an error while creating a new query plan (not implemented).

(Stardog server 7.0.3)

4

Hi Thorsten,

Can you share the error from the stardog.log file on your server?

Jess

5

When I run: ./stardog query my graph long-query.sparql -v
I get:

The detailed stack trace for the error is:
com.complexible.stardog.cli.CliException: There was an error while creating a new query plan
	at com.complexible.stardog.cli.impl.ConnectionCommand.call(ConnectionCommand.java:87)
	at com.complexible.stardog.cli.CLIBase.execute(CLIBase.java:55)
	at com.complexible.stardog.cli.CLI.main(CLI.java:110)
Caused by: com.complexible.stardog.protocols.http.client.BaseHttpClient$HttpClientException: There was an error while creating a new query plan
	at com.complexible.stardog.protocols.http.client.BaseHttpClient.checkResponseCode(BaseHttpClient.java:567)
	at com.complexible.stardog.protocols.http.client.BaseHttpClient.execute(BaseHttpClient.java:385)
	at com.complexible.stardog.protocols.http.client.HttpClientImpl.update(HttpClientImpl.java:270)
	at com.complexible.stardog.protocols.http.client.HttpConnection._update(HttpConnection.java:184)
	at com.complexible.stardog.api.impl.AbstractConnection.executeUpdate(AbstractConnection.java:484)
	at com.complexible.stardog.api.impl.UpdateQueryImpl.execute(UpdateQueryImpl.java:42)
	at com.complexible.stardog.api.impl.UpdateQueryImpl.execute(UpdateQueryImpl.java:22)
	at com.complexible.stardog.cli.impl.QueryWithOutput.writeOutput(QueryWithOutput.java:155)
	at com.complexible.stardog.cli.impl.Query.execute(Query.java:90)
	at com.complexible.stardog.cli.impl.ConnectionCommand.call(ConnectionCommand.java:75)
	... 2 more
Caused by: com.complexible.stardog.StardogException: There was an error while creating a new query plan
	at com.complexible.stardog.ErrorCodes.parseToThrowable(ErrorCodes.java:59)
	at com.complexible.stardog.protocols.http.client.BaseHttpClient.checkResponseCode(BaseHttpClient.java:534)
	... 11 more
6

Hi,

Is that the full stack trace from stardog.log, or the output from the client command? The server log would have the complete stack trace as well as (potentially) other helpful information for us to diagnose.

7

It's the output form the client "query" command. The server log (stardog.log) doesn't list a stack trace at all. Do I have to start Stardog with a special argument to obtain stack traces?

8

Hi Stardog team, is there any progress or insight to this issue yet? We would like to include Stardog to our list of supported backends but are blocked by this issue.

9

Hi Thorsten,

I can reproduce the issue. Will look into this and update this thread.

Best,
Pavel

10

Alright, here's what happens:

  • the original issue isn't about strdt(..), that function works as expected, but by default Stardog canonicalizes literals of certain datatypes, particularly, numerical. If you create the database with -o index.literals.canonical=false, you should see the literal converted to xsd:long. Then Stardog will treat "123"^^xsd:integer and "123"^^xsd:long as distinct RDF terms, otherwise (by default) the former will be chosen as the canonical. See the description of the option in Home | Stardog Documentation Latest

  • the problem with xsd:long is that there's no implementation for that specific cast function (I created a ticket for that). It'd be merely a convenience specialization of strdt and won't change the canonicalization behavior.

  • we are aware that some errors are not currently logged and that will be fixed in the next release.

Thanks for the patience!
Pavel

11

Hi Pavel,
Many thanks for this insight. Which issue number do I have to track in the release notes to see when this is done?
Thorsten

12

The xsd:long issue is #8411 and the error swallowing ticket is #8273.

Cheers,
Pavel