Re: SPARQL subset as a PATCH format for LDP

> 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.
> 
> 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?"
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).
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.
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


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead