In addition, the default format should not be fixed to "text/csv" but should vary with the query form.
It's not so easy to find it in a SPARQL query without parsing it.
One can make a guess: look for the first match of ^\s*(select|ask|construct|describe)\b (case-insensitive).
Or could use an external command arq.qparse (part of JENA)
Look at this twisted test.rq: the first keyword CONSTRUCT is a false positive, and select is hidden at the end of a line:
# CONSTRUCT {is not the form of this query}
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> select * {
values ?t {owl:Class owl:DatatypeProperty owl:ObjectProperty}
?x a ?t
filter(not exists {?x rdfs:isDefinedBy ?y})
}
The regex will fail miserably, but qparse outputs the query in a normal form, where SELECT is easy to detect:
This is all nice and good for SELECT and ASK queries.
However, CONSTRUCT and DESCRIBE queries return RDF formats not the above tabular formats. See this spec: https://www.w3.org/TR/sparql12-protocol/#query-success. I don't know if there's an authoritative list, so I posted https://github.com/w3c/rdf-concepts/issues/83 and you can see a list of 9 there.
@johanwk's new version https://github.com/johanwk/elot/blob/main/elot-defs.org#execute-sparql-using-robot checks for ttl vs csv depending on query form: but sparql-mode should support the various formats.
In addition, the default format should not be fixed to "text/csv" but should vary with the query form. It's not so easy to find it in a SPARQL query without parsing it.
^\s*(select|ask|construct|describe)\b
(case-insensitive).Look at this twisted
test.rq
: the first keywordCONSTRUCT
is a false positive, andselect
is hidden at the end of a line:The regex will fail miserably, but
qparse
outputs the query in a normal form, whereSELECT
is easy to detect: