W3C home > Mailing lists > Public > public-rdf-comments@w3.org > July 2017

Re: Proposed fixed version of N-Triples https://www.w3.org/TR/n-triples/ Section 7

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 3 Jul 2017 15:08:51 +0100
Message-Id: <EE8D45E9-F077-4AB2-8C0A-89E36A781E87@cyganiak.de>
Cc: Jan Wielemaker <J.Wielemaker@vu.nl>, 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>
To: Wouter Beek <wouter@triply.cc>

> On 3 Jul 2017, at 14:54, Wouter Beek <wouter@triply.cc> wrote:
> 
> Hi Richard, others,
>  
> 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.
> 
> True, but for a data consumer it is not possible to determine whether a document is formatted in canonical or in non-canonical N-Triples (except by fully parsing the document).

Yes. To find out whether a document is formatted in some language it is necessary to fully parse the document. That’s true of every language.

> Canonical and non-canonical N-Triples advertise the same Media Type in HTTP Content-Type headers and have the same extension in file names.  It's nice when data publishers use the canonical N-Triples format, but since the data consumer cannot anticipate that this is actually the case, this does not make the situation easier for her in practice.

My experience is exactly the opposite: When publishers and tools produce Canonical N-Triples, it makes my situation as a data consumer very much easier in practice, while in theory it doesn’t make a difference.

Best,
Richard



> 
> ---
> Best regards,
> Wouter Beek.
> 
> Email: wouter@triply.cc <mailto:wouter@triply.cc>
> WWW: http://triply.cc <http://triply.cc/>
> Tel: +31647674624 <tel:%2B31647674624>


Received on Monday, 3 July 2017 14:09:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:52 UTC