Re: SPARQL subset as a PATCH format for LDP

On Mon, Jul 28, 2014 at 9:47 AM, John Arwe <johnarwe@us.ibm.com> wrote:
>> 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.

Writing PATCHes by hand was never a requirement. For example, one can
use a framework tracking changes that happen in the domain model, and
reflect them in a PATCH to send to the server.

>>
>> Contrast that with LD-Patch, for which there is no other reason it.
>
> This sounds like selection bias writ large.
>
> It sounds completely logical if you're preaching to the RDF/SPARQL choir;
> otherwise, not so much.  The "REST" world?  They'd say "WTH is RDF?"

My team understand RDF/SPARQL pretty well, so that's not really an
issue for us, but this more like an A team, and I know by experience
that RDF/SPARQL doesn't fly easily in all environments.

>
> Devs will (do) learn whatever godawful syntax they need to in order to get
> their job done with API xyz; they do that now, it's Not New to them; google,
> stackoverflow, copy/paste, tweak. move on.  To first order today, that means
> JSON over HTTP, period.  And BTW, if the syntax happens to violate someone's
> standard, many of them if not most really don't care as long as they can do
> what they need to Right Now.  I've seen some Really Frightening things in
> HTTP APIs (marketed as "REST", of course), *especially* in the name of
> "partial updates" (aka Patch, most often by sending a partial representation
> on a PUT ... THAT kind of frightening).

That is also what I have seen. People quickly re-interpret standards
the way they want so that it satisfies their immediate use-case. And
they don't care about calling that REST, or using PUT for patching,
etc.  I've seen things you people wouldn't believe.

>
> RDF's one prayer today in terms of practical widespread (in Any Sense of
> that term) usage is JSON-compatible syntaxes, and those need convenient list
> processing or you'll lose the JSON crowd again.  Cripes, on a new API today
> my folks won't even consider anything like RDF unless it's JSON-LD compact
> (they'd happily use other things like RDF-JSON, I simply can use the OTS
> component + standard argument to get them on board).  Even then, they want
> the clients to treat it *as JSON* not as RDF, and that context node had
> better darn well not flow on the wire.

We need RDF, so we are finally moving away from JSON-LD to Turtle,
because we cannot depend too much of a context and a specific shape
for the JSON. The main reason is that JSON-LD doesn't play well with
inlining, which we rely on a lot.

That being said, just as in JSON-LD, we use rdf:list everywhere, and
we need a good support for it. And it's not like it's not already
happening: people are using JSON PATCH for patching JSON-LD, as in
[1]. And it's not any random guy in an obscure team doing that...

[1] https://web-payments.org/specs/source/identity-credentials/

>
> There are ~6K people in my area of IBM; they're more than happy to let me be
> the only one who understands RDF in any depth, and I have ZERO business need
> today to fuss with SPARQL.  I've seen at least a handful of products over
> the last 3 years that would have liked a "simple" (I know, I know) patch
> operation, mostly add/replace the literal object of a predicate whose
> occurrence within a graph is limited to 0:1.  If you make it cheaper and
> less risky for them to POST using their own syntax than to use OTS
> components, they'll continue to do that (or worse, ala the PUT +
> just-updated-triples pattern).  I see some applications where SPARQL is
> required, but at the moment we're not building those.
>
> If you give them a truly simple syntax that solves only 50% of their cases,
> they'd still love it to death.  KISSes

Agreed, and wanted to say (once again): in some situations, the cost
for SPARQL is just damn too high.

But we are turning in circles, and this is not a good use of my time.
I will wait for Arnaud to catch up on the thread. If the group
(finally!) wants to work on SPARQL, or not to support something along
the current LD Patch proposal, then I need to know it quickly, so that
I can just focus on finishing the spec with those interested in that
approach.

Alexandre

>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Cloud and Smarter Infrastructure OSLC Lead
>

Received on Monday, 28 July 2014 15:29:55 UTC