- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 30 Jul 2012 16:24:03 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-wg@w3.org
On Jul 30, 2012, at 3:38 PM, Andy Seaborne wrote: > > > 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. BUt surely IF this is a good idea and worth having, which Im assuming it is, then the longer we wait, the more problems there will be with deployed systems out there which don't support it. Kicking the can down the road is not a good way to handle problems of legacy inertia. Pat > > Andy > >> >> >>> Lee >>> >>>> Best, >>>> >>>> Nathan >>>> >>>> >>> >>> >> > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Monday, 30 July 2012 21:24:40 UTC