Re: Remaining Open Issues in Turtle

On Mon, 2012-05-14 at 19:11 -0700, Gavin Carothers wrote:
> And now, an editors opinons...

Thanks for putting this together, and your excellent work on Turtle. 
I'm really sorry, again, for bringing up this stuff so late in the
process.

> In general there seems to be a belief that we are "changing Turtle a
> lot". I'm a bit worried by this notion. We have talked about it for a
> while and made some changes to it. However right now all non
> pathological Turtle documents in the wild will have the exact same
> resulting RDF graph as they do today. Most documents that can be
> created using the "new Turtle" syntax will also work just fine with
> existing parsers today. The changes most likely to cause errors were
> also the least controversial. Numbers starting the local part of
> prefix names and blank node labels. Allowing ''' for long literals and
> not only """. These are places where people using Turtle today often
> encounter errors already.
> 
> On Mon, May 14, 2012 at 6:49 PM, Gavin Carothers <gavin@carothers.name> wrote:
> > 1.1) Change the allowed prefix keyword to include PREFIX (case
> > insensitive) in addition to @prefix (ISSUE-89)
> >
> > 1.2) Change the allowed base keyword to include BASE (case
> > insensitive) in addition to @base (ISSUE-89)
> >
> > 1.3) Remove required trailing period from directives (ISSUE-89)
> 
> -1
> 
> SPARQL is not Turtle. 

But we did resolve to align them, agreeing, "they should be the same
except for well-motivated (and small) exceptions."   (That doesn't
settle the issue, of course - it's unclear if this is well-motivated
and/or small.)

> In SPARQL PREFIX and BASE statements may only be
> at the top of a query and are separated from triple patterns by {}s.
> Queries have no design goal of being concatenated. It is unlikely
> (Imposible?) that dc: is bound to two IRIs in a query. In Turtle
> directives may occur anywhere in the document this makes visually
> identifying directives which change how prefix names and IRIs are
> resolved very important to the human reader. The @ very neatly sets
> them apart from surrounding triple statements.

Those are all valid reasons, as is Andy's concern about change at this
stage.   I just think users down the road are going to feel quite
differently.

I should point out: I'm also thinking in and about Trig these days, and
in Trig we have a more pointed version of this problem: do we have some
kind of GRAPH keyword?   If we use "GRAPH" as a keyword, then it can
look just like SPARQL:

    ...
    GRAPH <g1> { <s> <p> <o> }
    ...  

To make that be @graph would be too different from SPARQL to be useful,
but to have Trig have keywords "@prefix", "@base", and "graph" seems
particularly incoherent.

> > 2) Support top-level blank-predicate-object lists for example (ISSUE-19)
> >
> >        [
> >        foaf:name "Name" ;
> >        foaf:knows <http://example/another>
> >        ] .
> 
> +1
> 
> I think there was general agreement to do this and it simply got lost
> in the shuffle. In fact I even remember making the changes to one the
> grammars at one point. (No more using Yacker and not version control
> for me!)

I haven't been able to find this in the minutes (they're hard to search
-- my fault: I never got back to that code to implement the
all-resolutions-on-one-page feature I was planning on), but my memory
agrees.  I think it's fine to go ahead and make this change in the
document.

> > 3) Allow for the null prefix to be bound, for example (No ISSUE)
> >
> >   @prefix foaf: <http://xmlns.com/foaf/0.1/>.
> >   @prefix <http://example.com/Alice/personal#>.
> >
> >   Alice foaf:knows Bob, Charlie, Dave.
> 
> -1
> 
> ␀ is not a prefix, it's the lack of a prefix. If for some reason we
> wanted to add bare words to Turtle @prefix is a strange way to do it.
> I don't see any reason to add bare words to Turtle. Not to mention you
> run into 'a' ... which makes it a bit funky, and heck if combined with
> 1.1, 1.2 you also run into prefix and base... no, lets not do this.

As I said, this doesn't go well with dropping the @ -- but then, you're
opposed to dropping the @.  If we're keeping the @ on prefix and base,
then this seems like a perfectly reasonable thing to do, from a language
design perspective.  (And yes, "a" would remain an unfortunate
exception.)

I'm surprised you find it strange, thinking about new users.   In the
schema.org mentality, where there is only one namespace that nearly
everyone uses for nearly everything, ... it seems a little odd to me to
make everyone have to type a colon before every word they type.  
Really, it gets kind of tiring.   

Anyway, I'm certainly not going to lie in the road over this one, and
it's clear the WG doesn't like this idea.   It reminds me of the // in
URLs; we're so used to it, we've forgotten how silly it is.

     -- Sandro

> Cheers,
> Gavin
> 
>

Received on Tuesday, 15 May 2012 12:31:03 UTC