Re: SPARQL subset as a PATCH format for LDP

On 07/26/2014 02:55 PM, Alexandre Bertails wrote:
> On Sat, Jul 26, 2014 at 1:52 PM, Sandro Hawke <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.

>   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?

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].

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.

       -- 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> wrote:
>>>>> 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.
>>>>>
>>>> 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>
>>>>> 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 Saturday, 26 July 2014 21:59:16 UTC