- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Mon, 22 Aug 2011 18:40:01 +0100
- To: Zhe Wu <alan.wu@oracle.com>
- Cc: Steve Harris <steve.harris@garlik.com>, public-rdf-wg@w3.org
On 22 Aug 2011, at 17:16, Zhe Wu wrote: > Well, if we are talking about human interactions while a small piece of RDF is involved, Turtle may be a better choice? > If it is a huge piece of RDF, then presumably we want to use a triple store or a quad store to do the job. N-Triples is designed for *test cases*. It was never intended for large-scale machine-to-machine communication. It just happens to also work quite well for that. > Well if we are talking about two pieces of enterprise production software that have a mismatch in input/output format, the cost of fixing it is rather high. As long as both vendors have the new feature switched off by default in their new versions, the additional cost is *zero*. \u escapes won't be removed from the N-Triples format. Vendors who want to maximize compatibility will *accept* UTF-8 encoded N-Triples, but will continue to *emit* \u-escaped N-Triples by default for the next couple of years. > For some proof of concept sitting on a laptop, interoperability or backward compatibility is not much of a concern. We've got twelve billion triples sitting on a nice little cluster in DERI. I'm not interested in laptops. > I would probably change it to something like "Formats/Systems that cannot support international characters are slowly disappearing" Off the top of my head, I can't think of any format defined in the last decade that explicitly forbids the use of UTF-8 like N-Triples does. (I'm sure there are some, but it doesn't appear to be common.) In a world where UTF-16 and UTF-8 increasingly become universal, one actually has to do extra work to transmit plain US-ASCII. I'd really prefer an outcome where steps are taken towards removing that extra burden. Best, Richard
Received on Monday, 22 August 2011 17:40:31 UTC