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

On 07/03/2017 04:52 PM, David Booth wrote:
> 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.

Funny. Actually I didn't want to get that far. I only wanted to limit
the freedom to what is currently being used in practice, claiming that
more freedom harms and doesn't do any good. A week ago I didn't even
know it as allowed to omit white space between the three components. It
was Wouter Beek who found out while scraping loads of wild RDF from the
web.

After your suggestion you have a point though. Canonical N-triples are
very easy to handle and generate and as N-triples is merely a
machine-to-machine protocol no freedom is perfectly ok.  Of course this
would require some more thought ...

 Cheers --- Jan

Received on Tuesday, 4 July 2017 16:13:17 UTC