Re: GRAPH keyword in Turtle, PREFIX vs @prefix (was Re: Deprecate most "native" RDF serializations)

On 6 May 2012, at 06:01, Sandro Hawke wrote:

> On Sat, 2012-05-05 at 21:08 -0700, Gavin Carothers wrote:
>> On Sat, May 5, 2012 at 8:11 PM, Sandro Hawke <sandro@w3.org> wrote:
>>> On Sat, 2012-05-05 at 19:50 -0700, Gavin Carothers wrote:
>>>> On Sat, May 5, 2012 at 5:54 PM, Sandro Hawke <sandro@w3.org> wrote:
>>>>> On Fri, 2012-05-04 at 11:22 -0400, Manu Sporny wrote:
>>>>>> 
>>>>>> """
>>>>>> TURTLE Lite would effectively be a subset of TURTLE - N-Quads, or
>>>>>> something that would be N-Quads-like (allowing for either "s p o" or
>>>>>> "s
>>>>>> p o c" statements).
>>>>>> """
>>>>>> 
>>>>>> Gavin has asserted that TURTLE already supports N-Triples... now all
>>>>>> we
>>>>>> need to do is to make N-Quads a subset of TURTLE and we're good for
>>>>>> TURTLE Lite.
>>>>> 
>>>>> Since a subset can't include things not in its superset, I guess you're
>>>>> saying that Turtle should include the dataset/quad stuff?  Do you have a
>>>>> proposed syntax for that?   I don't think adding the label after the
>>>>> triple, as in N-Quads, works well in Turtle...
>>>>> 
>>>>> s p o1 g, o2 g; p2 o3 g.
>>>>> 
>>>>> Nah.   Maybe just like trig, where you have a triple you could have
>>>>> label + { graph }.   Or maybe a GRAPH keyword like in SPARQL.  I kind of
>>>>> like that.
>>>> 
>>>> Yes, had proposed adding @graph to Turtle. There wasn't support for
>>>> doing so. Too much of a change to the language.
>>> 
>>> It might be more accurate to say there was more opposition than support
>>> at the time.   There was some support.   Manu might be offering more --
>>> and, more to the point, he's making a new argument that might
>>> potentially be supported by data.   (He's arguing for simplicity to
>>> appeal to potential adopters.  RDF experts are in some cases the worst
>>> people to assess that kind of argument.)
>> 
>> See http://www.w3.org/2011/rdf-wg/wiki/Graphs-In-Turtle
>> Email thread http://lists.w3.org/Archives/Public/public-rdf-wg/2011Sep/0170.html
>> Minutes http://www.w3.org/2011/rdf-wg/meeting/2011-09-28
> 
> Thanks for digging this up.   It's funny how these things come around
> again, barely remembered.
> 
> One thing I don't see in the @graph discussion is the idea of more
> strongly aligning with TURTLE, using the exact SPARQL syntax
> 
>   triples
>   GRAPH id { triples }
>   GRAPH id { triples }
> 
> which is appealing to me, especially given Manu pointing out the emperor
> has way too many syntaxes.   As a newcomer working with Turtle and
> SPARQL, moving between @prefix and PREFIX, and maybe @graph and
> GRAPH, ...?    Well, I might be a judgmental newcomer, but I'd probably
> look around for some rotten to vegetables to throw at those W3C folks.
> 
>> This was close to my initial argument as well 7 months ago. Publishing
>> Turtle as a preferred way to publish RDF at the same as publishing a
>> new recommendation about named graphs and not being able to use named
>> graphs in Turtle seems poor. Also existing implementations today
>> already use special comments in Turtle documents to support something
>> very like named graphs. 8 months ago figured I'd wait to worry about
>> this more till we settled on named graph support in the next 3 months
>> ... yeah ... 
> 
> Yeah.   :-(   :-(       The pace of progress is here is depressing.

Just to repeat: Garlik/Experian will formally object to any definition of Turtle that allows named graphs to be specified.

It would make it *unsafe* to consume any Turtle file we found in the wild, up to now this has not been the case with Turtle, RDF/XML, or N-Triples.

- Steve

>> The nearness of a Turtle LC and the ongoing
>> confusion/conversation/whatever on named graphs is reducing my own
>> support for trying to support "named graphs" in Turtle.
> 
> I understand.    
> 
> I wonder if there's any way to thread this needle -- not holding back
> Turtle, but not closing the door to this thing that I suspect is going
> to seem like a no-brainer, looking back in a couple of years.
> 
> Procedurally, we could put it in as At Risk, asking for community
> feedback.   This would require some spec changes, talking about
> generating quads instead of triples.   I'd be willing to help with that.
> 
>> This likely
>> means that if whatever we come up with for named graphs sees wide
>> adoption more people will move towards TriG (or whatever Turtle like
>> multi graph format) as the default format rather than
>> Turtle/N-Triples. Lee Feigenbaum already comments to that effect in
>> the thread. If your using multi graphs today, you can't really use
>> Turtle.
>> 
>>> 
>>> Other than backward compatibility -- which we're breaking on other
>>> places already, can you think of any reason we're using @prefix instead
>>> of SPARQL's PREFIX?
>> 
>> At this time we have non compliant PARSERS. All existing Turtle
>> documents should still be valid Turtle documents (with possible very
>> odd edge cases), if this is not the case then I would consider it a
>> bug in the new specification. Saying that old parsers are not
>> compliant is very different than saying that old documents are not
>> Turtle any more.
> 
> Thanks for clarifying that.    So my proposal here is that the turtle
> language be defined with both "@prefix" and "prefix", with a note that
> "@prefix" is included for backward compatibility and should not be used
> in "new" documents.  (I put "new" in quotes, because there will be some
> transition period, as people wait for the old turtle parsers to be
> replaced.)
> 
>    -- Sandro
> 
>>> 
>>> -- Sandro
>>> 
>>>>> 
>>>>> Steve has argued very strongly, and Andy just mentioned again, that
>>>>> people want to know from the mime type whether they'll be getting
>>>>> triples or quads.   Steve sees it as a big security issue -- you don't
>>>>> want to load quads in from the Web and have them over-write your
>>>>> crawler's internal state metadata or data that was supposedly fetched
>>>>> from other address. I'm not convinced, myself, not at all, because I
>>>>> think one needs to have an "untrusted" mode of loading quads that
>>>>> renames all the graphs.
>>>>> 
>>>>>   -- Sandro
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> 

-- 
Steve Harris, CTO
Garlik, a part of Experian 
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, Nottinghamshire, England NG80 1ZZ

Received on Tuesday, 8 May 2012 17:55:04 UTC