Issues with returning typed literals

[cem-okulmus]

Hello,

I notice that knakk/sparql only returns typed literals when the JSON bindings from the Sparql endpoint actually have as type "typed-literal". I notice that GraphDB a supposedly standard compliant Sparql database, never returns "typed-literal" as the type of literals, only ever "literal". Here an example:

{
"head" : {
"vars" : [
"sub",
"path",
"ClosedObjTest"
]
},
"results" : {
"bindings" : [
{
"sub" : {
"type" : "uri",
"value" : "http://datashapes.org/sh/tests/core/complex/personexample.test#Calvin"
},
"path" : {
"type" : "uri",
"value" : "http://datashapes.org/sh/tests/core/complex/personexample.test#birthDate"
},
"ClosedObjTest" : {
"datatype" : "http://www.w3.org/2001/XMLSchema#date",
"type" : "literal",
"value" : "1999-09-09"
}
}
]
}
}

Note that "ClosedObjTest" is a "literal", but still has type date. This causes the Term that is parsed from this JSON to drop the type and just have string. I'm not sure if this is a problem with this package, or with GraphDB, but at any rate it seems to me that the most pragmatic solution is to check if the binding returns a "datatype" that is not string, and to carry that information when producing the Term struct.

Not sure if the solution I outline above is desirable. I will fork and implement this "hotfix" of sorts for my project and I could make it into a pull request if that's wanted.

[boutros]

When I developed this I mainly worked against virtuoso, so it might be somethign specific for that implementation. If you manage to make it work for both literal and typed-literal with datatype I will probably merge it.

I belive this is the spec: https://www.w3.org/TR/2013/REC-sparql11-results-json-20130321/

Edit: according to above document, this "typed-literal" was something in earlier version of the spec, and not recommended anymore:

typed-literal" existed in the pre-recommendation working group note from the original SPARQL working group.

So I guess its due to the age of this package, almost 10 years since I started, only working against openlink virtuoso at the time.

[cem-okulmus]

I am currently on a project where I'm not working with virtuoso, and it probably makes sense to test this against multiple systems before merging it. Will come back to this a bit later down the line.

[cem-okulmus]

So, I had a look at what Virtuoso is doing, at least in the open source version, which is the only one I have access to. When I run a simple query like

SELECT 32 WHERE {}

it returns (as JSON):

{ "head": { "link": [], "vars": ["callret-0"] },
"results": { "distinct": false, "ordered": true, "bindings": [
{ "callret-0": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#integer", "value": "32" }} ] } }

So we see that Virtuoso still uses the old "typed-literal" value. The way I implemented things in my fork, it simply checks for values with type "literal" whether "datatype" is defined, and then simply recovers this value, instead of using xsd:string as the type, like the old code did. And the behaviour for "typed-literal" is of course unchanged.

If this solution sounds acceptable, then I could prepare a Pull Request.

[boutros]

Sounds good to me!