- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 30 Jul 2012 23:37:27 +0100
- To: public-rdf-wg@w3.org
On 30/07/12 22:24, Pat Hayes wrote: > > 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. > Your argument would apply to literals-as-subjects as well; it's largely a syntax restriction. If that's going to happen, it isn't in this WG (by charter), so why not make the changes in one step, not in multiple steps? And it is a big IF. I see some evidence for it in Turtle but, frankly, not much. It's not like something can't be expressed anyway; it's a style thing that some (how many?) things are better written one and no another. The counter evidence is how long Turtle has been going without it. The original request was for "is ... of" as a reverse path, not "^". "^" is one of two path operators and it introduces a bNodes [1] (by the text - the grammar and text don't quite line up but then N3 grammar is wider than the language which is fine, it's just the approach taken). There is another path operator in N3 "!" (which was "." if you read the tutorial) used after a property to indicate forward traversal. Of the arguments originally put for "is..of", the avoidance of the anti-pattern of defining the inverse named property is valid. The question is how much is it worth? At the moment, there isn't a detailed proposal on the table with all the issues considered analytically. Andy [1] http://www.w3.org/TeamSubmission/n3/#path """ The reverse traversal, x^p means [ p x ] """ > 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 22:37:56 UTC