Re: Comment on SPARQL 1.1 CSV Results

Thanks Lee - changes based on that text.

[[
The standard CSV format does not distinguish between missing values and 
empty strings. The SPARQL 1.1 CSV Results Format uses the same 
representation for unbound variables as for variables bound to an empty 
string literal. The other SPARQL Result formats (based on JSON, TSV or 
XML) can be used if this distinction is required.
]]

	Andy

On 06/02/12 14:11, Lee Feigenbaum wrote:
> Perhaps something like:
>
> """
> Note that the standard CSV format does not distinguish between missing
> values and empty strings. Because of this, the SPARQL 1.1 CSV Results
> Format uses the same representation for unbound variables as for
> variables bound to an empty string literal. Clients that require the
> ability to distinguish between these two cases should use the TSV, XML,
> or JSON results format instead of the CSV format.
> """
>
> Lee
>
> On 2/6/2012 4:08 AM, Andy Seaborne wrote:
>> Greg, Lee,
>>
>> I presume you agree with option 1 then.
>>
>> What wording do you suggest in section 3.2 or elsewhere?
>>
>> Andy
>>
>> On 06/02/12 01:52, Gregory Williams wrote:
>>> On Feb 5, 2012, at 7:46 PM, Eric Prud'hommeaux wrote:
>>>
>>>> On Sun, Feb 5, 2012 at 18:57, Lee Feigenbaum<lee@thefigtrees.net>
>>>> wrote:
>>>>> I agree with Greg.
>>>>>
>>>>> Given that the CSV format is purposefully simple and lossy, I think
>>>>> that
>>>>> unbound variables and empty strings should both be empty strings in
>>>>> CSV,
>>>>> which can be either ,, or ,"",
>>>>
>>>> I believe the use of existing libraries argument is more salient for
>>>> parsers than for serializers (i.e. printf loops). What then is the
>>>> harm in specifying the "" distinction, which only some parsers will
>>>> distinguish?
>>>
>>> While CSV is a trivial format, I'd suggest that it's not just a matter
>>> of "printf loops". There still is escaping to be done, and leaving it
>>> to a library is always safer than trying to hack it together in a loop.
>>>
>>> Also, I'm worried about us trying to define semantics based on
>>> syntactic variations that are specified as being equivalent. It's no
>>> longer 'just CSV' if we're ascribing semantics to whether you use ,,
>>> or ,"",. The CSV format is inherently lossy, so I'm not sure why this
>>> particular case should be any more of an issue than others.
>>>
>>> .greg
>>>
>>>
>>
>>
>

Received on Monday, 13 February 2012 13:07:33 UTC