Clojurians Log v2

> there’s no standard that even says triple stores should support text/csv The standard does specify how text/csv should be formatted for SELECT response: https://www.w3.org/TR/sparql11-results-csv-tsv/. The issue is that for ASK queries it seems to be undefined. > or map the result to a non standard that looks something like My tentative solution is to just manually return a true or false string since that is (as long as you add the right EOF chars) technically valid CSV or TSV. I think for a case like this, it would be better to return some information to the user rather than give them no info in a 406.

Ahh yes you’re right, my bad, I should have double checked to remind myself - it’s been 6 years since I last implemented the specs for sparql and the sparql protocol, though I’ve done it twice! Regardless I think the two options I mention are your options… 1. Return a 406 (and essentially insist they either set application/sparql-results+(json|xml) 2. Return a CSV with some boolean column in it with the true or false as the value. In my experience some endpoints do 1 (e.g. stardog - and our drafter endpoints do) whilst others e.g. fuseki allow for 2, even though it’s non standard. I wouldn’t return just true or false though, but would also return a header row to ensure the format is at least structurally the same as what is mandated by the sparql-results csv-tsv spec. The problem then is that the choice of column name is not standardised…. We fudge this on our SPARQL query UI to look like tables (even though we implement option 1 underneath) and call the column boolean, whilst fuseki calls the column _askResult. Personally I think 1 is the most correct option and it encourages portability and correct handling of sparql query types and content types in client code. i.e. clients wont risk ever falling outside of the standard as might if you offered this extension. It’s probably also worth mentioning that a lot of the behaviour rests on RFC2616; and that providing endpoints implement content negotiation properly that one option which means clients can avoid having to detect/parse the query type is to NOT support text/csv for ASK queries but to allow clients to declare they can accept multiple Accept headers. i.e. a client could send: Accept: text/csv,application/sparql-results+json,text/turtle And then it can determine the query type by attempting to parse the response as JSON, turtle and finally csv (though actually why bother with CSV at all here). Personally I prefer option 1, as it encourages users and clients to be standards compliant… though if clients were written against fuseki they may accidentally be depending on _askResult as a column in their CSV. So 🤷 YMMV

Incidentally I seem to vaguely recall some endpoints supporting text/plain for ASK queries; which would just return true or false, but again it’s non standard.

Hmm digging into https://w3c.github.io/rdf-tests/sparql11/data-sparql11/protocol/index.html#http://www.w3.org/2009/sparql/docs/tests/data-sparql11/protocol/manifest#query_content_type_construct, you can clearly see that it's not expected that ASK queries support CSV or TSV responses. So you're definitely onto something.

Yeah I'm building my own /sparql endpoint here

yes you’re right — I’d forgotten and should have double checked!