- From: Sandro Hawke <sandro@w3.org>
- Date: Sun, 27 Jul 2014 10:58:21 -0400
- To: Andrei Sambra <andrei.sambra@gmail.com>
- CC: Alexandre Bertails <alexandre@bertails.org>, ashok malhotra <ashok.malhotra@oracle.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <53D5138D.5020004@w3.org>
On 07/27/2014 09:37 AM, Andrei Sambra wrote: > > > > On Sat, Jul 26, 2014 at 11:35 PM, Sandro Hawke <sandro@w3.org > <mailto:sandro@w3.org>> wrote: > > On 07/26/2014 10:20 PM, Alexandre Bertails wrote: > > On Sat, Jul 26, 2014 at 5:59 PM, Sandro Hawke <sandro@w3.org > <mailto:sandro@w3.org>> wrote: > > On 07/26/2014 02:55 PM, Alexandre Bertails wrote: > > On Sat, Jul 26, 2014 at 1:52 PM, Sandro Hawke > <sandro@w3.org <mailto:sandro@w3.org>> wrote: > > On 07/26/2014 01:44 PM, Ashok Malhotra wrote: > > Hi Sandro: > Thanks for the pointers. I read some of the > mail and the conclusion I > came > to seems a bit different from what you > concluded. I did not see a big > push for > SPARQL. Instead I found from > http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Jul/0206.html: > > "The other possibilities, no matter what the > outcome of the workshop, > *are* > ready to be standardized and I rather suspect > some work on combining the > best elements of each will get us much > further, must faster than trying > to > mature ShEx." > > So, this argues for leading with existing > solutions, ICV and SPIN, > rather > than > with ShEX because the other solution have some > implementation and > experience > behind them. Makes perfect sense. > > But the PATCH case seems to be different as > AFAIK there are no other > existing > solutions. > > We can always argue if they are suitable for the > problem, but other > existing/potential solutions include: SPARQL Update in > full, 2 subsets > of SPARQL Update, and RDF Patch + skolemization. > > Isn't SPARQL UPDATE an existing solution for PATCH? > > It serves the basic purpose, although it has some > drawbacks, like bad > worst-case performance and being fairly hard to > implement. > > Those same things, however, could quite reasonably > be said about ICV and > SPIN. > > I don't know about ICV, SPIN or ShEx (ok, just a > little bit, maybe). > > > To be clear, they are only relevant as another example of > how inventing > something which could be done by SPARQL (even if > painfully) gets a lot of > pushback. > > Have you considered that the pushback _could_ be justified? > > For example, I really like SPARQL, for several reasons, but as > I have > explained, I really think it is not appropriate as a PATCH > format for > LDP. > > > I just have two remarks: > > * SPARQL Update as a whole was developed for RDF > databases, namely > quad stores, with expressive power from the rest of > SPARQL. I don't > know if it was designed with use-cases as in RDF > Validation, but I do > know it was not designed for the use-case of updating > LDP-RS on the > LDP platform. > * building a technology on top of an existing one is > something I tend > to prefer whenever it makes sense. But in our case, we > are talking > about taking the subset of an existing language, while > remaining > compatible with it. This is *not* as easy as it seems > at first. > > I would prefer to hear about concrete proposals on how > to do that. As > somebody who _cannot_ rely on an existing SPARQL > implementations, and > who is not planning to implement one in full for that > use-case, I > would like to see a concrete syntax written down, with > a formal > semantics for it. > > > Okay, I'm going to make two concrete proposals. > > 1. Just use SPARQL 1.1 Update. The whole thing. I > know it doesn't > handle lists well. What else is wrong with it? Why can > you not use it? > > I became interested in LDP because it was the first time RDF was > becoming a first-class citizen of the Web, by that I mean > applications > can interact (read/write) *directly* with RDF resources using > HTTP, > without being behind an endpoint. That's what we meant by LDP > being > the intersection of RDF and REST. > > The W3C has finally recognized a few years ago that native RDF > was not > the only use-case for RDF applications. You can now have a > relational > database (RDB2RDF), CSV files (RDF for Tabular Data), XML (GRDDL, > XSLT), etc. But not necessarily a triple/quad store. For > example, at > the company I work for, we have several (ie. physically > disconnected) > Datomic and Cassandra servers, and we are now exposing some of the > data behind LDP, with the objective of doing for all of our > data. In > all those cases, we want to expose and link our data on the > Web, like > all those so-called RESTful APIs, but in a more consistent > way, and > using RDF as the model and the exchange data format. Hence > LDP, and > not yet-another-web-api. > > The reason I am telling you all that is that supporting SPARQL for > those virtual RDF datasets is not that easy (when possible) > when you > don't have a quadstore as your backend. Reverse mapping for simple > SPARQL queries is hard. And SPARQL Update is even worse to > support. > Basically, forcing SPARQL Update onto LDP facing applications for > simple resource updates on single LDP-RS (ie. PATCH) is like > using a > hammer to kill a fly. > > So full SPARQL Update is simply a no-go for me. I just cannot > support > it completely, as some features cannot correctly be mapped to > Datomic > and Cassandra. > > > So this is the key. You want to be able to support PATCH on > databases that are not materialized as either triples OR as SQL. > > If the database was SQL, then (as I understand it), SPARQL Update > would be okay, because it can be mapped to SQL. > > But you don't know how to map SPARQL Update to NoSQL databases, or > it's just too much work. > > I take it you do know how to map LD-Patch to Cassandra and Datomic? > > [ BTW, Datomic sounds awesome. Is it as fun to use as I'd imagine? ] > > > > > Also, if I was in a case where SPARQL Update was ok for me to use > (it's not), then I suspect that I wouldn't need LDP at all, > and SPARQL > + Update + Graph Store protocol would just be enough. And there is > nothing preventing one from using SPARQL Update right now. > Just don't > call it LD Patch. > > > It's not about what's called what, it's about what we promote as > the the PATCH format. If we had a simple enough PATCH format, > then we could possibly make it a MUST to implement in the next > version of LDP. > > > I think Alexandre makes a valid point. For a spec (LDP) that > explicitly tried to avoid SPARQL, using this format for PATCH makes > absolutely no sense to me. > > > I don't think SPARQL Update is simple enough for that, but my > prediction is the LD-Patch will turn out, sadly, to not be either. > > > > 2. Use SPARQL 1.1 Update with an extension to handle > lists well. > Specifically, it would be a slice function, usable in > FILTER and especially > in BIND. This seems like a no-brainer to include in > SPARQL 1.2. I'd want > to talk to a few of the SPARQL implementers and see if > they're up for adding > it. Maybe a full set of list functions like [1]. > > Sorry but I don't know RIF and your idea is still very vague > for me. I > understand how you can provide new functions for matching > nodes in an > rdf:list but I fail to see how this plays in a SPARQL Update > query. > > Can you just provide some examples where you are doing the > equivalent > of that python code (I know read python): > > > Probably not worthwhile to go into this now, given your veto on > SPARQL. > > > > [[ > > l = [1,2,3,4,5,6,7,8,9,10] > l[2:2] = [11,12] > l[2:7] = [13,14] > l[2:] = [15,16] > l.append(17) > > ]] > > If we want a subset, we could define it purely by > restricting the grammar -- > eg leaving out the stuff that does federation, negation, > aggregation, -- > with no need to say anything about the semantics except > they are the same as > SPARQL. Until I hear what the problem is with SPARQL, > though, I don't want > to start excluding stuff. > > Am I the only one thinking that "no need to say anything about the > semantics except they are the same as SPARQL" is just plain wrong? > > I mean, would we really tell implementers and users of the > technology > that they have to go learn SPARQL before they can start > understanding > what subset correctly apply to LD Patch? And how? And would > they still > need to carry this ResultSet semantics over while a lot of us > would > explicitly prefer avoiding it? > > > I think the users who are writing PATCHes by hand will be familiar > with SPARQL. And if they are not, there are lots of other reasons > to learn it. > > > Except that LDP explicitly made a point to avoid SPARQL. Since the LDP > model is all about interacting with resources by using their > individual URIs, PATCH-ing resources through a SPARQL endpoint goes > against the core LDP believes. > Note that no one is proposing using a SPARQL endpoint -- just that SPARQL Update be used as a HTTP PATCH format. (This is an idea that the SPARQL WG also suggested for GSP.) -- Sandro > -- Andrei > > > Contrast that with LD-Patch, for which there is no other reason it. > > You seem to think LD-Patch's syntax and semantics are easy. I > don't think they are. Maybe if you expanded the path syntax only > many rows it would be more clear what it means. > > I can't help but regret again that we didn't chose to use > TurtlePatch (which I first wrote on your wall, the week after the > workshop - even if I didn't figure out how to handle bnodes until > this year). https://www.w3.org/2001/sw/wiki/TurtlePatch > > -- Sandro > > > > Alexandre > > -- Sandro > > > [1] > http://www.w3.org/TR/rif-dtb/#Functions_and_Predicates_on_RIF_Lists > > > > Alexandre > > -- Sandro > > > All the best, Ashok > On 7/26/2014 6:10 AM, Sandro Hawke wrote: > > On July 25, 2014 2:48:28 PM EDT, Alexandre > Bertails > <alexandre@bertails.org > <mailto:alexandre@bertails.org>> wrote: > > On Fri, Jul 25, 2014 at 11:51 AM, > Ashok Malhotra > <ashok.malhotra@oracle.com > <mailto:ashok.malhotra@oracle.com>> wrote: > > Alexandre: > The W3C held a RDF Validation > Workshop last year. > One of the questions that > immediately came up was > "We can use SPARQL to validate > RDF". The answer was > that SPARQL was to complex and too > hard to learn. > So, we compromised and the > workshop recommended > that a new RDF validation language > should be developed > to cover the simple cases and > SPARQL could be used when > things got complex. > > It seems to me that you can make a > similar argument > for RDF Patch. > > I totally agree with that. > > Thanks for bringing this up, Ashok. I'm > going to use the same > situation to argue the opposite. > > It's relatively easy for a group of > people, especially at a face to > face > meeting, too come to the conclusion SPARQL > is too hard to learn and we > should invent something else. But when > we took it to the wider > world, we > got a reaction that's so strong it's hard > not to characterize as > violent. > > You might want to read: > > > http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Jul/thread.html > > Probably the most recent ones right now > give a decent summary and you > don't have to read them all. > > I have lots of theories to explain the > disparity. Like: people who > have > freely chosen to join an expedition are > naturally more inclined to go > somewhere interesting. > > I'm not saying we can't invent something > new, but be sure to understand > the battle to get it standardized may be > harder than just implementing > SPARQL everywhere. > > - Sandro > > Alexandre > > All the best, Ashok > > > On 7/25/2014 9:34 AM, Alexandre > Bertails wrote: > > On Fri, Jul 25, 2014 at 8:04 > AM, John Arwe > <johnarwe@us.ibm.com > <mailto:johnarwe@us.ibm.com>> > > wrote: > > Another problem is the > support for rdf:list. > I have just finished > writing down the > semantics for > UpdateList and based > on that > experience, I know > this is something I > want to rely on as a user, > because it is so easy > to get it wrong, so I > want native support > > for > > it. And I don't think > it is possible to do > something equivalent in > SPARQL Update. That is > a huge drawback as > list manipulation (eg. > > in > > JSON-LD, or Turtle) is > an everyday task. > > Is semantics for > UpdateList (that you > wrote down) somewhere that > > WG > > members > can look at it, and > satisfy themselves that > they agree with your > conclusion? > > You can find the semantics at > [1]. Even if still written in > Scala > > for > > now, this is written in a > (purely functional) style, > which is very > close to the formalism that > will be used for the operational > > semantics > > in the spec. Also, note that > this is the most complex part > of the > entire semantics, all the rest > being pretty simple, even > Paths. And > > I > > spent a lot of time finding > the general solution while > breaking it > > in > > simpler sub-parts. > > In a nutshell, you have 3 > steps: first you move to the > left bound, > then you gather triples to > delete until the right bound, > and you > finally insert the new triples > in the middle. It's really tricky > because 1. you want to > minimize the number of > operations, even if > > this > > is only a spec 2. unlike usual > linked lists with pointers, you > manipulate triples, so the > pointer in question is only > the node in > > the > > object position in the triple, > and you need to remember and carry > > the > > corresponding > subject-predicate 3. > interesting (ie. weird) things > > can > > happen at the limits of the > list if you don't pay attention. > > [1] > > https://github.com/betehess/banana-rdf/blob/ldpatch/patch/src/main/scala/Semantics.scala#L62 > > I'm not steeped enough in > the intracacies of SPARQL > Update to have > > a > > horse > in this race, but if this > issue is the big-animal > difference then > > people > > with the necessary > understanding are going to > want to see the > > details. > > The > IBM products I'm aware of > eschew rdf:List (and blank > nodes > > generally, to > > first order), so I don't > know how much this one > alone would sway > > me. > > You _could_ generate a SPARQL > Update query that would do > something > equivalent. But you'd have to > match and remember the > intermediate > nodes/triples. > > JSON-LD users manipulate lists > on a day-to-day basis. Without > native > support for rdf:list in LD > Patch, I would turn to JSON > PATCH to > manipulate those lists. > > It sounds like the other > big-animal difference in > your email is > > we would have to > refine the SPARQL > semantics so that the > order of > > the > > clauses matters (ie. > no need to depend on a > query optimiser). And > > we > > That sounds like a more > general problem. It might > mean, in effect, > > that > > no > one would be able to use > existing off-the-shelf > componentry (specs > > & code > > ... is that the > implication, Those Who > Know S-U?) and that might > > well be > > a > solid answer to "why not > [use S-U]?" > > The fact that reordering the > clauses doesn't change the > semantics is > > a > > feature of SPARQL. It means > that queries can be rearranged for > optimisation purposes. But you > never know if the execution > plan will > be the best one, and you can > end up with huge intermediate > result > sets. > > In any case, if we ever go > down the SPARQL Update way, I > will ask > > that > > we specify that clauses are > executed in order, or > something like > > that. > > And I will ask for a semantics > that doesn't rely on result > sets if > possible. > > Were there any other > big-animal issues you > found, those two aside? > > A big issue for me will be to > correctly explain the subset > of SPARQL > we would be considering, and > its limitations compared to > its big > brother. > > Also, if you don't implement > it from scratch and want to > rely on an > existing implementation, you > would still have to reject all the > correct SPARQL queries, and > that can be tricky too, > because you have > to inspect the query after it > is parsed. Oh, and I will make > sure > there are tests rejecting such > queries :-) > > Alexandre > > Best Regards, John > > Voice US 845-435-9470 > <tel:845-435-9470> BluePages > Cloud and Smarter > Infrastructure OSLC Lead > > > > >
Received on Sunday, 27 July 2014 14:58:32 UTC