Feature idea: fx:json.literalize option to treat JSON subtrees as literals

[rybesh]

Proposal

Define an option fx:json.literalize that takes a JSON key as a value. When processing JSON, values associated with this key will become literal values created by stringifying the JSON value. By default it would produce strings, but a datatype URI could be provided to produce another datatype (e.g. geo:geoJSONLiteral)

Motivation

GeoSPARQL 1.1 defines a datatype for GeoJSON literals, geo:geoJSONLiteral. Example:

"""
{"type": "Point", "coordinates": [-83.38,33.95]}
"""^^<http://www.opengis.net/ont/geosparql#geoJSONLiteral>

Currently the JSON triplifier parses entire JSON trees into RDF. When it does this with GeoJSON geometry objects like the Point above, it turns them into RDF lists. (This gets very ugly with MultiPolygons.)

But we never want to access individual coordinate values in GeoJSON geometry objects. We do not want to “open them up” at all; instead they should be treated as opaque literal values.

[rybesh]

If this is something that makes sense to do, I would be interested in working on it.

[justin2004]

you could do the last part of that with https://www.w3.org/TR/sparql11-query/#func-strdt

but you'd need sparql anything to present you the raw (json) string value

[justin2004]

maybe we need/want a function that says "don't triplify this key -- just give me the raw string"

[rybesh]

Yes. I was thinking of a configuration option (e.g. for GeoJSON files we would set the key for which raw JSON strings should be returned to geometry), so that ideally we would never create triples for those subtrees in the first place. I feel like this would also speed up processing of GeoJSON files which potentially have very large nested arrays under geometry keys.

[enridaga]

Hi @rybesh -- this seems to make a lot of sense. I would also add that a generalised solution would be useful, as I've seen similar situations with the XML content as well. So, if you want to explore how to implement something like that for JSON, that could be a good start. You have my full support :)

[Sychic]

Hey, I've currently implemented this on our fork of Sparql Anything, however now that I'm testing our fork in our own environment, I'm running into some issues. We currently provide the location for our Sparql Anything service clause through the cli (through the argument -c location=path/to/input) but this seems to have broken after v1.0-DEV.1. I'm unable to run versions v1.0-DEV.2-5 as they all throw errors. Everything up to commit 40af01d also seems to not work. I've attached a log snippet below:

> graph/roman-provinces.ttl
[main] WARN org.apache.sis.system - The “SIS_DATA” environment variable is not set.
[main] ERROR io.github.sparqlanything.engine.PropertyExtractor - Neither location nor content provided
[main] WARN io.github.sparqlanything.engine.FXWorkerOpService - No triplifier found
[main] WARN org.apache.jena.sparql.engine.iterator.QueryIteratorCheck - Open iterator: QueryIterRoot/0

Please let me know if you need any more information.

[enridaga]

I reproduced it and opened #526 -- thanks for the heads up!