- From: David Booth <david@dbooth.org>
- Date: Mon, 3 Jul 2017 10:52:43 -0400
- To: Jan Wielemaker <J.Wielemaker@vu.nl>, Richard Cyganiak <richard@cyganiak.de>
- Cc: Wouter Beek <wouter@triply.cc>, Gregg Kellogg <gregg@greggkellogg.net>, Dan Brickley <danbri@google.com>, Ivan Herman <ivan@w3.org>, public-rdf-comments Comments <public-rdf-comments@w3.org>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
On 07/03/2017 09:50 AM, Jan Wielemaker wrote: > On 07/03/2017 03:26 PM, Richard Cyganiak wrote: [ . . . ] >> The N-Triples document defines two languages: “N-Triples” and >> “Canonical N-Triples”. The latter requires a single space between RDF >> terms and does not permit comments, and is reasonably well-suited to >> processing with line-based text tools. Producers are encouraged to >> produce Canonical N-Triples. > > I know that. I only do not see why we want to make our non-canonical > triples as non-canonical as possible and as close as possible to being > ambiguous rather than enforcing current practice that makes the triples > more readable, easier to process and allows for better error messages. > I.e., where is the benefit of doing so? If I'm following your line of thinking, it sounds like you are saying that we should only have defined *Canonical N-Triples* language, and not defined N-Triples, because Canonical N-Triples is easy to generate by machine, and if you are hand writing triples then they can be parsed as Turtle anyway (since N-Triples is a subset of Turtle). Thus, the (non-canonical) N-Triples language is unnecessary. Interesting and fair point. I wonder what would break if we deprecated N-Triples in favor of Canonical N-Triples. David Booth
Received on Monday, 3 July 2017 14:53:16 UTC