Skip to content

Instantly share code, notes, and snippets.

Created May 16, 2013 02:40
What would you like to do?
Description of changes to make to Turtle regarding PrEfIx

PrEfIx and BaSe should be removed from Turtle

PREFIX and BASE were added as features at risk to Turtle before CR. Designed to make it easier to copy and paste between Turtle and SPARQL they have proven controversial. As they are a controversial addition to a settled language they should be removed.


The FPWD for the Turtle document published by this working group included the following:

Turtle is already a reasonably settled serialization of RDF. Many implementations of Turtle already exist, we are hoping for feedback from those existing implementers and other people deciding that now would be a good time to support Turtle. There are still a few rough edges that need polishing, and better alignment with the SPARQL triple patterns. The working group does not expect to make any large changes to the existing syntax.

The laudable goal of reducing copy and paste errors in both Turtle and SPARQL is not strong enough to change a settled serialization.

None of the arguments in support of the feature deal with what serialization should be preferred. Introducing the feature also creates issues with the existing @prefix and @base syntax and if they should or should not require a trailing period. Again, there is no clear guidance for serializers. This feature also introduces the first case insensitive keyword in Turtle all other Turtle keywords are case sensitive.

Lastly, the goal of full copy and paste between SPARQL and Turtle will not be achieved only by adding this feature. A range of other issues exist preventing this.


  • Remove "Feature at Risk" box
  • Remove grammar rules 5s, 6s
  • Update grammar rule 3 to read prefixID | base
  • Change grammar note 1 to "All keywords are case sensitive"

The grammar at that point requires no magical understanding of case rules as all rules express the case of their keywords.

Ways forward for those that like copying and pasting PREFIX/BASE

I'd direct your attention to the conformance section of the Turtle document. "This specification does not define how Turtle parsers handle non-conforming input documents." That note is not there by mistake.

Selected Messages and Threads (From outside of WG)

Yes, I read all the threads again, just a few are included here.


David Booth

Copy and paste between Turtle and SPARQL is very common, particularly in debugging. Having to change the prefix syntax back and forth is a significant and pointless waste of time. Please find a path to a single compatible syntax.

In opposition

Gregory Williams 2013-03-01:

I'd like to take this opportunity to provide feedback on the inclusion of SPARQL BASE and PREFIX syntax in the new Turtle grammar. I think this is a mistake, adding complexity for both users and implementors. I'm sympathetic to the desire to align syntax for triples between Turtle and SPARQL, but don't believe the alignment is necessary or recommended for the top-level language syntax (as the need for backwards compatibility with pre-REC Turtle means that alignment requires two different syntaxes for the same declarations).

David Robillard 2012-10-08:

For what it's worth, as a Turtle implementer I am opposed to this change. It is ugly and inconsistent with the language, clearly an import that does not belong.

While it is unfortunate that SPARQL did not use the @directive convention from N3, Turtle does not contain SELECT and such either. While triple copying and pasting between the languages is desirable (even if it has polluted Turtle with path grammar and horrific escaping rules), the directives between the two languages are not compatible.

I do not consider messing up the Turtle specification in this way appropriate. If implementations want to support this as an extension, they may. I won't.

Peter Ansell 2013-04-28

I am sorry, but I completely disagree that changing a fundamental part of an established syntax as part of its long-delayed "standardisation" process can be rationalised by saying that hypothetical future users will appreciate it and it doesn't matter what a community of current users think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment