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

On May 10, 2012, at 12:50, Sandro Hawke wrote:

> On Wed, 2012-05-09 at 18:42 +0000, RDF Working Group Issue Tracker
> wrote:
>> RDF-ISSUE-89 (at-prefix): Should Turtle allow SPARQL's PREFIX like @prefix? [RDF Turtle]
>> 
>> http://www.w3.org/2011/rdf-wg/track/issues/89
>> 
>> 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: <http://xmlns.com/foaf/0.1/>.
>        @prefix : <http://example.com/Alice/personal#>.
> 
>        :Alice foaf:knows :Bob, :Charlie, :Dave.
> 
> or
> 
>        prefix foaf: <http://xmlns.com/foaf/0.1/>.
>        prefix <http://example.com/Alice/personal#>.
> 
>        Alice foaf:knows Bob, Charlie, Dave.
> 
> Does anyone doubt the second example would win overwhelmingly?


Having taught undergrads and grad students Turtle and SPARQL, I do think there are some didactic objections to the second form:

1.  The barewords aren't obviously tied to anything.  How is a new student of the language supposed to understand what can and can't go there?

2.  The ':' serves as a useful indication that the term is to be treated as a URI.  Barewords for URI fragments don't capture that.

However, I do think that aligning SPARQL and Turtle prefix and base terms (and dealing with the trailing full stops when appropriate) is useful.  Unlike Steve, I have both complained about them and heard complaints, mostly when documents fail validation.

Regards,
Dave

> 
> 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 Friday, 11 May 2012 15:12:59 UTC