W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2011

Re: Oracle's stand regarding N-TRIPLES

From: Zhe Wu <alan.wu@oracle.com>
Date: Mon, 22 Aug 2011 11:14:03 -0700
Message-ID: <4E529C6B.5090506@oracle.com>
To: Pat Hayes <phayes@ihmc.us>
CC: Richard Cyganiak <richard@cyganiak.de>, Steve Harris <steve.harris@garlik.com>, public-rdf-wg@w3.org
Hi Pat,
> Actually, no. It is just plain better for all but a tiny fraction of human readers, anywhere on the planet. This tiny fraction includes some software engineers. I personally will simply ignore any string that contains \u escapes, and immediately cease using any software that shows them to me. And I suspect that more people share my instincts than share yours.
>

I don't think N-TRIPLES is an end user oriented format. It's originally designed for Test cases as pointed out by Jeremy. It
happens to be used (quite well actually) by large-scale machine to machine communication as pointed out by Richard. I would
dare say that the chance to see \u from a User Interface of a semantic web application is very low.

Thanks,

Zhe



> Pat Hayes
>
>> To me personally, seeing that encoded string is better than a string containing characters that I don't read.
>> On the Linux terminal I am using, I can't even cut&  paste that string. It only gets the "Gro" portion right.
>>
>> I understand the perspective of developer usability and a possible escaping cost for implementation on
>> some platforms. However, none of them seems to be significant enough to justify all the potential interoperability,
>> and backward compatibility issues.
>>
>> Thanks,
>>
>> Zhe
>>
>>
>> On 8/21/2011 8:06 AM, Richard Cyganiak wrote:
>>> Zhe,
>>>
>>> On 20 Aug 2011, at 02:34, Zhe Wu wrote:
>>>> I don't see how adding UTF8 encoding can make N-TRIPLES much more useful.
>>> For data debugging and developer usability, seeing "Großräschen" in an N-Triples document is better than seeing "Gro\u00DFr\u00E4schen".
>>>
>>> It also decreases the cost of implementing N-Triples serializers, because they can now directly emit UTF-8 strings rather than requiring a custom escaping routine for handling non-US-ASCII characters.
>>>
>>> Best,
>>> Richard
>>
>>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
Received on Monday, 22 August 2011 18:14:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT