Data type struggle with Map and Map+
Wilbert Kraan
Not sure whether this list is meant for usage discussions, and I'm not sure that I've got an issue, so I hope you'll forgive me if I've missed something.
I've set up a query that closely follows gvlizler's Map+ example- the url is given below. It works great in gtable, but any attempt to run it in Map+ (or Map, with the "" and ?url variables deleted) results in "The columns type does not match the supported data format. See documentation for supported formats."
I use XML as the output format (JSON doesn't work with this endpoint via gvizler, though I can get JSON out of the endpoint manually)
Some testing reveals that the SPARQL endpoint sees the lat long values as strings. Those data are not typed at source. As far as I can see, SPARQL does not let you casts strings as integers for the final response- it'll only use datatype casting for sorting and filtering.
Since a lot of RDF isn't typed, I wonder whether it is worth relaxing the data type constraints on Map and Map+ - if that is indeed the issue here.
Cheers,
Wilbert
http://www.ovod.net/wilbert/linkedData/viz/sgvizler.html?query=PREFIX+foaf%3A+%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0D%0APREFIX+jisc%3A+%3Chttp%3A%2F%2Fwww.rkbexplorer.com%2Fontologies%2Fjisc%23%3E%0D%0APREFIX+doap%3A+%3Chttp%3A%2F%2Fusefulinc.com%2Fns%2Fdoap%23%3E%0D%0APREFIX+prod%3A+%3Chttp%3A%2F%2Fprod.cetis.ac.uk%2Fvocab%2F%3E%0D%0APREFIX+mu%3A+%3Chttp%3A%2F%2Fwww.jiscmu.ac.uk%2Fschema%2Fmuweb%2F%3E%0D%0APREFIX+geo%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%0D%0ASELECT+DISTINCT+%3Flat+%3Flong+%3Fname+%22%22+%3Furl%0D%0AWHERE+{+%0D%0A%3Furl+a+doap%3AProject+.%0D%0A%3Furl+jisc%3Ashort-name+%3Fname+.%0D%0A%3Furl+jisc%3Aend-date+%3Fdate+.%0D%0A%3Furl+doap%3Avendor+%3Forg+.%0D%0A%3Forg+owl%3AsameAs+%3Ffb+.%0D%0A%3FjmuID+owl%3AsameAs+%3Ffb+.%0D%0A%3FjmuID+a+mu%3AOrganisation+.%0D%0A%3FjmuID+mu%3ACountry+%22Scotland%22+.%0D%0A%3FjmuID+geo%3Alat+%3Flat+.%0D%0A%3FjmuID+geo%3Along+%3Flong+.%0D%0AFILTER+%28+%3Fdate+%3C+%222011-10-22T00%3A00%3A00%22^^xsd%3AdateTime+%29%0D%0A}%0D%0AORDER+BY+xsd%3Aint%28%3Flong%29+DESC%28xsd%3Aint%28%3Flat%29%29&width=800&height=400&chart=gTable
"Martin G. Skjæveland"
> Hello,
>
> Not sure whether this list is meant for usage discussions, and I'm not sure that I've got an issue, so I hope you'll forgive me if I've missed something.
This list is, at least for the time being, meant to be used for anything
about Sgvizler.
> I've set up a query that closely follows gvlizler's Map+ example- the url is given below. It works great in gtable, but any attempt to run it in Map+ (or Map, with the "" and ?url variables deleted) results in "The columns type does not match the supported data format. See documentation for supported formats."
>
> Some testing reveals that the SPARQL endpoint sees the lat long values as strings. Those data are not typed at source. As far as I can see, SPARQL does not let you casts strings as integers for the final response- it'll only use datatype casting for sorting and filtering.
It is true that these chart types require the lats and longs to be of
the "javascript" datatype number, which it becomes if the values
returned by the SPARQL endpoint is one of xsd:int, float, .. and so on.
gtable accepts any datatypes.
It is possible to type the results, e.g.,
SELECT DISTINCT xsd:float(?lat) xsd:float(?long) "" ?name ?url
A working query link is pasted in below.
> Since a lot of RDF isn't typed, I wonder whether it is worth relaxing the data type constraints on Map and Map+ - if that is indeed the issue here.
Yes, this is a good idea. I will make at least Map+ more forgiving to
"incorrect" input, i.e., numbers which are not typed as numbers. (The
Map chart type just forwards everything to Google, so Map+ is easier for
me to modify.)
> I use XML as the output format (JSON doesn't work with this endpoint
> via gvizler, though I can get JSON out of the endpoint manually)
Hmmm.. I'll see if I can find what the problem is.
> Cheers,
>
> Wilbert
Thanks!
Martin
Wilbert Kraan
Ah, floats! I'd tried integers in a fairly random fashion (it seems to be the one area in the SPARQL spec doc without an example...), but didn't get anywhere. Many thanks- that's generally very useful to know.
The JSON issue may have been a fluke: I've tested it again with various settings for endpoint_output and endpoint_query_url, and it seems to work now.
Many thanks!
Wilbert