Re: in...of syntax Re: Turtle Last Call: Request for Review

* Andy Seaborne <andy.seaborne@epimorphics.com> [2012-07-30 21:38+0100]
> 
> 
> On 30/07/12 14:20, Eric Prud'hommeaux wrote:
> >* Lee Feigenbaum <lee@thefigtrees.net> [2012-07-30 08:56-0400]
> >>On 7/30/2012 7:41 AM, Nathan wrote:
> >>>
> >>>>This WG has been trying to move Turtle and SPARQL closer
> >>>>together.
> >>>>
> >>>>One is a syntactic transformation (Turtle), the other is part
> >>>>of the mechanism for pattern matching, so they need explaining
> >>>>differently. SPARQL ^ is much more general.
> >>>>
> >>>>And hence,
> >>>>
> >>>>SPARQL Update does not support ^:p in INSERT DATA
> >>>>
> >>>>because it's not a matching operation.
> >>>
> >>>Yes, because Turtle is a syntax, and SPARQL is a query language
> >>>(as you well know), that deviation is already there, the two are
> >>>different specs for different purposes, however can and do share
> >>>some syntax. For example: Do we have TURTLE Update? or Turtle
> >>>?s, or Turtle SELECT? or Turtle ASK? No because it's not a
> >>>querying language, and it doesn't require a matching operation.
> >>>
> >>
> >>INSERT DATA is inserting data by specifying it with a syntax. It's
> >>not doing any querying.
> >
> >I think the point remains that we have a pair of assertion language
> >and query language which are nicely matched in that every assertion
> >can be transplanted to the query language and match that assertion.
> >If we add ^:p, it seems that remains true, though it does add some
> >pressure to add that syntax to the CONSTRUCT and update parts of the
> >query language.
> >
> >I'm sort ambivalent about doing this now vs, putting it off for
> >later. Doing it now would be less work overall (we don't need to
> >invent a version number or have people serializing ^:p's cross their
> >fingers hoping consumers' parsers are up to snuff.
> 
> I don't think the issue is quite like that.
> 
> 1/ Given the number of existing Turtle parsers already out there,
> isn't that where we already are?  They may not meet the LC spec
> perfectly but they are all close and doing a fine job today.
> 
> >OTOH, it would be
> >nice to get this out before starting another engineering cycle. I
> >guess a +.5 for doing this now. Corresponding -.5 for doing it later,
> >and -.2 for not doing it at all.
> 
> 2/ SPARQL Update has completed last call, SPARQL Query is now in
> (final?) last call.  When does all this small scale refining?  The
> only consistent I see approaches are halt SPARQL until RDF is ready
> or take what we have.  Adding just "one more feature" does not seem
> viable.
> 
> The engineering for SPARQL 1.1 is basically done - there are systems
> already out there.
> 
> So if it were a clean slate, I'd agree with you, but I don't think
> it is, either for Turtle or SPARQL.

I totally agree that it's not a clean slate, but I'm not sure how that
changes the cost/benefit ratios for doing it now, later or not at all.
Fatigue and market impatience may be more important.

> 	Andy
> 
> >
> >
> >>Lee
> >>
> >>>Best,
> >>>
> >>>Nathan
> >>>
> >>>
> >>
> >>
> >
> 

-- 
-ericP

Received on Monday, 30 July 2012 20:47:59 UTC