- From: Alexandre Bertails <alexandre@bertails.org>
- Date: Fri, 25 Jul 2014 14:48:28 -0400
- To: ashok.malhotra@oracle.com
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
On Fri, Jul 25, 2014 at 11:51 AM, Ashok Malhotra <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. 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> 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 BluePages >>> Cloud and Smarter Infrastructure OSLC Lead >>> > >
Received on Friday, 25 July 2014 18:48:55 UTC