- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 14 Jun 2011 18:20:50 +0100
- To: Steve Harris <steve.harris@garlik.com>
- CC: public-rdf-dawg@w3.org
On 14/06/11 18:03, Steve Harris wrote: > On 2011-06-14, at 12:38, Andy Seaborne wrote: >> >> On 14/06/11 12:04, Steve Harris wrote: >>> Quick mini-review: >>> >>> Abstract >>> >>> 4store answers ASK in TSV as "true", but it should probably be >>> "ask\ntrue" or similar. >> >> Yes, it would have to be if it's TSV compatible, the header line is needed - whether an first empty record is (in practical terms) is safe, I don't know. > > I think it would be friendlier on libraries to include a header. I agree, it is generally better but there are cases where an implementation may wish not to. Hence the language is: """ The SPARQL CSV Results Format SHOULD use of a header row. If the header row is not present, this MUST be indicated by content type parameter header=absent. """ SHOULD (RFC 2119) is quite strong [[ there may exist valid reasons in particular circumstances to ignore a particular item ]] and MUST is included so the default is defined. Because CSV allows it, I think we should aim for maximum interoperability - We are not registering text/sparql-results+csv. A column of number for use in a larger spreadsheet table of results (so the column is meaningless) is such particular circumstance. >>> 3.1 >>> >>> What's the purpose of allowing the header line to be absent? Does any >>> system do this now? It makes it tricky for consumers, and I prefer to >>> MUST the header for SPARQL results. >> >> Because the CVS does not require it - TSV does. It agree it's better to include it but I think SHOULD is as strong as we can get, given that the CSV spec itself does not mandate it. > > True, but there are for example things that are legal by the TSV spec that wouldn't be valid SPARQL Results, e.g. > > ?foo > <f > > so I don't have any issue with us imposing restrictions over and above what the base spec says. > >> It does make some sense to omit if its being read into a spreadsheet as >> a table of numbers. The point of CVS is consumption of information without RDF parsing. > > I think that's rather a corner case though, how would the server > even know that it's a spreadsheet, and that you didn't want headings, > spreadsheets softly expect them too, e.g. in data operations. It means > we win some issues around the column ordering, which is a little lose > e.g. in SELECT *. > > SELECT * > WHERE { > ?x :val1 ?v1; > :val2 ?v2; > :val3 ?v3. > > etc. > >>> Why no ? preceeding the header out of interest? I guess it goes with >>> the STR(?val) in the data rows? >> >> Yes - CSV when read directly into a spreadsheet, the spreadsheet may well print the column names. This is a good use of CSV over TSV. >> >> The variable is called "var", not "?var". So, like the rest of the CSV format, it's strings. > > Fair enough. > >>> 4.1 >>> >>> Prefer requiring ? 5store uses $ for historical reasons, but 4store >>> uses ? >> >> I prefer choosing one char and ? is more common but I thought I'd at least point it out. > > OK, consider this another vote for ?. That's +2 then. Andy > > - Steve > >>> On 2011-06-13, at 14:47, Andy Seaborne wrote: >>> >>>> The content is now complete. >>>> >>>> http://www.w3.org/2009/sparql/docs/csv-tsv-results/results-csv-tsv.html >>>> >>>> >>>> >> To do: >>>> >>>> + More complete examples + References need folding into the ReSpec >>>> reference database (which is why there are two references sections >>>> currently, and you see [ [ABC] ] markers). + Do we add ASK answers >>>> as well? (and what is the header line for ASK? TSV requires one - >>>> empty?) >>>> >>>> Comments and feedback would be most welcome. >>>> >>>> Andy >>>> >>> >> >
Received on Tuesday, 14 June 2011 17:21:22 UTC