What is the advantage of N-Triples over CSV for storing RDF triples? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

N-Triples is a line based serialization format for an RDF graph. Each line represents the subject, predicate and object of an RDF Triple separated by whitespace and ended with a dot like:

<http://one.example/subject1> <http://one.example/predicate1> <http://one.example/object1> . 

More details can be found here: http://www.w3.org/TR/n-triples/

But why is it necessary to define such a format, if one could serialize RDF Triples simply using CSV like

http://one.example/subject1, http://one.example/predicate1, http://one.example/object1

I could even easily extend to support N-Quads, N-Quints, ... using CSV. What are the advantages of N-Triples over CSV for serializing RDF triples?

Answer 1

Disclaimer: I'm the original editor of N-Triples and implemented it in Raptor http://librdf.org/raptor/ both the N-Triples original and the 2013 version.

There are multiple answers to this but it's basically ambiguity. CSV can't distinguish between a URI that looks like http://foo.com/ and a string http://foo.com/

In CSV

http://foo.com/,http://foo.com/,http://foo.com/

this could be a triple

(URI http://foo.com/, URI http://foo.com/, URI http://foo.com/)

or

(URI http://foo.com/, URI http://foo.com/, Literal http://foo.com/)

N-Triples adds <> and "" for distinguishing these cases