JSON+LD/RDF serialization of SPARQL queries

[JervenBolleman]

Upto now SPARQL has been defined as a string of characters. However, there is a wish for an easier to manipulate format of queries.

Why?

It is currently difficult to give back feedback to users regarding how their query was executed and can be improved. Systems that do this need to patch query strings, which even for simple cases like automatically adding OFFSET and LIMIT clauses in the right place of a query string is not straight forward.

This feature would be basic building block for sharing query execution plans as an RDF/JSON+LD query object can be extended to as in the strawman example below that there is an error and the kind of join type planned by the DB.

SELECT ?somethingBad ?badClass WHERE { ?somethingBad a ?badClass , "bad" }

{"base": "<http://example/base/>",
 "project" : 
    {"variables" : [ "?somethingBad", "?badClass" ],
    "source" : 
        { "bgp" : [
            { "@type" : "triple" , 
            "subject" : "?somethingBad" ,
            "predicate" :  "rdf:type",
            "object" :  "?badClass" },
            { "@type" : "triple" , 
            "subject" : "?somethingBad" ,
            "predicate" :  "rdf:type",
            "object" :  "bad" ,
            "_error_" : "Error: can't have a literal for a type in our well designed system" },
        "_join_" : "join:hash"
        }
    }
}

The basics can be build from the SPARQL algebra model.

The desire for a JSON+LD model is so that it can be embedded in a application/sparql-results+json(+ld) result set.

Previous work

The SPIN notation has an notation for SPARQL in RDF.

Considerations for backward compatibility

SPARQL 1.0 and 1.1 only understand a query string, and do not expect JSON or RDF in a query field.
Suggestion is to add a new standard form parameter e.g. rdfquery for the http protocol.

Extending the formats of application/sparql-results with new fields can break many clients in the field.

[dydra]

why would one not handle this through simple content negotiation?
see, for example, the "inspect" menu here.
that menu specifies an alternative accept media type for the sparql request.
when one is working on their own repository, the menu contains numerous entries.

as demonstrated there, each - including the execution reports, entails its own request.
if the requirement is to comprise several in a single request/response, then one could use multipart responses.

[tfrancart]

Related work : SPARQL.js as a JSON (not LD) representation of SPARQL queries : https://github.com/RubenVerborgh/SPARQL.js

[VladimirAlexiev]

Related work: SSE (sparql query algebra), eg

• http://sparql.org/query-validator.html: check all checkboxes and compare
• https://dydra.com/jhacker/foaf/construct.sse?accept=application/VND.DYDRA.SPARQL-QUERY-ALGEBRA

[rubensworks]

Related work : SPARQL.js as a JSON (not LD) representation of SPARQL queries : https://github.com/RubenVerborgh/SPARQL.js

Some more related work:

• @joachimvh's SPARQLAlgebra.js builds upon SPARQL.js to adhere (as much as possible) to the SPARQL algebra.
• GraphQL-LD is a way to convert GraphQL queries into SPARQL, which offers an alternative, but more restrictive SPARQL serialization.

[jindrichmynarz]

Would it be acceptable to require clients to compile the structured syntax of SPARQL queries to plain text? That way this change could be introduced gradually, starting without changes in the SPARQL 1.1 Protocol.

A few years ago I wrote a post exploring several ways how to generate SPARQL. Now I'm leaning on using a data DSL, using a common data format, such as JSON, which maps to native data structures in mainstream programming languages. SPIN RDF or other RDF syntaxes are a bit cumbersome, because the syntax of SPARQL requires explicit ordering that is clumsy to represent and manipulate in RDF.

[joernhees]

I agree that exchanging a query in a structured format rather than just a string would be beneficial in many cases (e.g., to put the parsed (maybe implicitly changed) query into the query result, maybe also as a basis for execution plans, etc. for debugging and other purposes).

I however don't think that this should be limited to or favor RDF/JSON-LD.