Re: RDF-ISSUE-89 (at-prefix): Should Turtle allow SPARQL's PREFIX like @prefix? [RDF Turtle]

On Wed, 2012-05-09 at 18:42 +0000, RDF Working Group Issue Tracker
> RDF-ISSUE-89 (at-prefix): Should Turtle allow SPARQL's PREFIX like @prefix? [RDF Turtle]
> Raised by: Sandro Hawke
> On product: RDF Turtle
> The syntaxes of Turtle and SPARQL are very strongly aligned.   There's one glaring difference now, I think.  Turtle has people use "@prefix" to declare their namespace prefixes, but SPARQL uses "PREFIX".
> Surely this is going to confuse and frustrate users.
> PROPOSED: Turtle be defined to allow either @prefix or PREFIX, with PREFIX preferred and used in all the examples. 

BTW, I'm sorry for bringing this up so late in the process, but I didn't
step back far enough, earlier, to see it clearly.   Like the rest of
you, I've seen and used Turtle (and N3) for so long I'm quite used to
the mandatory at-sign on the prefix and base keywords.

But when I imagine introducing new people to Turtle, as I expect to be
doing for many years once it becomes a Recommendation, I can't think of
any way to justify that odd character.

Similarly, while we're on the subject, I can't think of any way to
justify the need for the colon as part of the prefixedName, when the
prefix is empty.      (Call fixing this 'the barewords proposal' which
isn't part of issue-89.)

There is an argument (below) that we couldn't do both of these changes.
But to not do either one seems to me to do a grave disservice to our
future potential users, and (incidentally) to everyone hoping we'll draw
in a lot of users.

We could do this experiment:  find a couple people who've used at least
one formal language before, but never seen Turtle or SPARQL, and ask
them which of these looks like a language they'd rather use:

        @prefix foaf: <>.
        @prefix : <>.
        :Alice foaf:knows :Bob, :Charlie, :Dave.


        prefix foaf: <>.
        prefix <>.
        Alice foaf:knows Bob, Charlie, Dave.
Does anyone doubt the second example would win overwhelmingly?

A few objections:

* Backward compatibility.  But we're already requiring parsers to change
to accept W3C-standard Turtle; the at-sign change is a trivial thing to
change; barewords is a little harder.  In either case, we would not be
affecting existing documents by doing this.

* Stability.  Yes, it's nice to say that Std Turtle is the same as the
Turtle you've known and loved for years.   True, but the faithful will
bear with slightly extending the syntax.  In exchange, they get
something closer to SPARQL (for the at-sign proposal), easier to type,
and nicer for newcomers.

* If we did both, there would be some barewords that might be keywords
in a future version of the language.   That might change the meaning of
old documents or make them syntactically invalid.  (This is why the @ is
there in the first place in n3.)   I can see this as an argument against
doing both...  Turtle might not get any keywords, but we probably will
add them to SPARQL.  

* The barewords proposal makes it diverge from SPARQL.   True.  And
SPARQL wants to keep adding new keywords, probably, going forward.  So,
that's a real blow against barewords (and why I only proposed the
at-sign issue as a problem, not the lack of barewords.)

I know we're feeling done with Turtle and want to get it out the door.
I just can't, in good conscience, ignore what seems like a clear win for
millions of future Turtle users.

    -- Sandro

Received on Thursday, 10 May 2012 16:50:41 UTC