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
>>>>
>>>
>>
>