W3C home > Mailing lists > Public > public-ldp-wg@w3.org > June 2013

Re: RDF Patch - Recording changes to an RDF Dataset

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Sun, 23 Jun 2013 23:28:32 -0400
To: Andy Seaborne <andy@apache.org>
CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-ID: <CDED09B5.FD91%erik.wilde@emc.com>
hello andy.

On 2013-06-23 11:20 , "Andy Seaborne" <andy@apache.org> wrote:
>JSON patch - it is actually quite similar in style.  There is an
>operation, a path and optionally value.  XML patch is of the same style
>- more complicated because the XML data model is more complicated.  Both
>use another language to describe the place in the document.  The use of
>xpath expressions means it isn't just XML; same for JSON paths on a
>smaller scale.

yes, you're right that patch operations need some way to identify what
they're operating on, but that seems quite natural, since you're basically
standardizing operators. but that doesn't mean that you cannot reuse the
metamodel of what you're patching. you need to understand the XML Patch
vocabulary (which uses XPath) to be able to apply a patch. but you can
still use a standard XML parser to parse it, before you start processing
it according to the rules of the vocabulary.

>RDF patch is similar to an N-Quads file with an operation field added.
>It also applies to a collection of RDF graphs.

it may be that i am missing some RDF-specific issues here. i was generally
commenting on the fact that it's useful to use the available toolbox of a
metamodel (parsers, for example) to do the first step of implementing a
patch processor. i think in JSON and XML, there would have been quite a
bit of backlash against using non-JSON or non-XML syntax, but like i said,
maybe there's something specifically different in RDF where this kind of
design has its distinct advantages.

cheers,

dret.
Received on Monday, 24 June 2013 03:29:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:51 UTC