SPARQL Profile for PATCH [was Re: LDP Patch Format FPWD published]

- Implementers could simply plug in an existing general-purpose SPARQL engine

if SPARQL is linked-data's SQL, it should have INSERT.. and does, no?

particularly with SPARQL's smaller niche, implementing everything, from SPARQL-Update to property-paths is a lot to bite off. you're likely to end up with a rather large product and only a few full implementations.. maybe ORACLE, Franz, something from Apache with a SAAS sponsor

many apps/CMSes/publishing-engines have emerged built on simple (and even cloud/webservice-hosted) key/value stores or distributed-filesystems full of .json files rather than what was en vogue a decade ago, fancy Python/Ruby "ORMs" abstracting away SQL (they'd already decided they didnt like it). digging around old Multics/CTSS docs there were query tools resembling SQL's modern syntax 40 years ago and given all the installs it's likely here to stay for at least another century. so if you're a fan i wouldn't worry..

this in the spirit of minimum-viable-product and more flexibility in implementation choices (your LD-PATCH might affect a runtime graph-store, a collection of files, or you might even save the patches themselves and 'replay' them starting at snapshots like some of the more exotic (darcs/bzr/mercurial) versioning-systems)

there's precedent, widespread-usage, and longevity of KISS-principle patching-means
PATCH(1)                    General Commands Manual                   PATCH(1)

alexandre says "the editors challenged themselves for not adding higher-level features"

Received on Saturday, 20 September 2014 04:34:26 UTC