From RDF Working Group Wiki
Proposals for TF-Turtle related deliverables
This page lists proposals that arose in the TF-Turtle task force for addressing the work item “Standardize Turtle Syntax” and “Either that syntax or a related syntax should also support multiple graphs and graph stores”.
@@@todo add media types
Proposals in scope of Turtle task force
A minimally improved version of the Turtle team submission, adding the following items:
- alignment with SPARQL triple pattern syntax
- mapping from Turtle to triples
- adding in ... of reverse syntax compatible with N3
If some version of Qurtle is standardized, then it could be in the same specification.
Improved version of N-Triples, with additions to make it more convenient, yet keeping the general simplicity and line-based approach.
- separate spec (currently it's a subchapter in as defined in RDF Test Cases)
- base URI + relative URIs
- own media type (not
With regards to the charter, this is on the edge. It can be argued to be a general cleanup activity. Usually, a spec should start with some sort of member submission, which we don't have here, but we have the “plain” N-Triples as defined in RDF Test Cases.
If some version of N-Quads is standardized, then it could be in the same specification.
Just standardize the tokens
Another option would be to just standardize the syntactic tokens, such as URIs, literals, blank nodes, and variables, so that other specs (including SPARQL?) can reference them and thereby become more interoperable. Others outside of the WG could continue to innovate with formats such as N3, TriG, N-Quads, RDF-Tuples etc
Proposals in scope of Graphs task force
Superset of Turtle, extended with optional support for naming graphs. Probably should use TriG as a starting point. Should be a subset of N3.
Improved version of N-Quads, with additions to make it more convenient, yet keeping the general simplicity and line-based approach. The fourth element is optional; when absent, the triple is thought to be part of the default graph. Syntactically, this is a superset of N-Triples and N-Triples++.
- base URI + relative URIs
- own media type
- allow only URIs as fourth element (currently, any RDF node is allowed)
- clarify scope of blank nodes (currently, the spec leaves this undefined)
Advantages over Qurtle:
- One can argue that it fulfills the charter requirement of a Turtle-based multigraph format, while being much simpler than Qurtle/TriG
- Currently, N-Quads are mostly used for dumps. Evidence for demand for a “small-scale”/readable multi-graph syntax is limited (but see Cambridge Semantics use case). N-Quads++ could address the use case for a multi-graph Turtle-like syntax while being simpler and more convenient for dump processing than Qurtle.
- This could work not just as a quad format but also supersede N-Triples. Disadvantage: losing N-Triples as a predictable super-simple triples-only format, e.g., for exchanging messages in a clustered triple store or storage in HBase tables in Sindice
N-Quads without triples
Like N-Quads (likely with elements from N-Quads++), but without being a syntactic superset of N-Triples. For triples in the default graph, require the fourth element to be something like
Advantages over N-Quads and N-Quads++:
- Parsers know beforehand if they will possibly encounter quads in the file
- N-Triples can still be safely processed by web crawlers etc without precautions for maliciously named graphs
Proposals likely out of scope
Superset of Plain Turtle, extended with more syntactic sugar, such as:
- Reverse properties:
:London ^foaf:basedNear :Alice
- Externalizing namespace declarations into RDFa-style profiles
This would however not extend to support for graph naming; that would be Qurtle.
This is most likely not in scope of the charter, except for any syntactic sugar that is already in other specs (SPARQL).
Not a graph format - this is "CSV for RDF". Motivation: easy-to-consume RDF data.
An RDF-Tuple is one line of RDF terms, in a subset of Turtle term syntax (no prefixes, with number abbreviations). SPARQL Variables are allowed.
A SPARQL result set might be:
?x ?y <http://example/> 123
- If done carefully, these files could open directly in Excel and other spreadsheet apps.
- This would fit better into the SPARQL WG, but it would reference Turtle syntax and therefore can't easily be done there.
- This would most likely be just a NOTE not a REC.