- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Tue, 12 Mar 2013 15:40:20 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR-s6pSGvchJVP-VQ=jQh-XJFSX1dTEVn0zfTF1Qk9O-Wg@mail.gmail.com>
I agree with Andy regarding global names, and their replacement by predicates. I also agree that the examples with bnodes in [1] are problematic, and that bnodes should probably not be allowed in the DELETE part. After all, we can still use PUT for this situation. pa [1] - http://open-services.net/wiki/core/OSLC-Core-Partial-Update/ On Mon, Mar 11, 2013 at 2:25 PM, Andy Seaborne < andy.seaborne@epimorphics.com> wrote: > Because you are labelling/naming the graph in a local context (the file) > with a global name. > > I disagree with: > """ > A pre-defined named graph that represents the nodes to match or to > insert is sufficient. > """ > > Your 'oslc:deleteGraph' graph isn't my 'oslc:deleteGraph'. > > Test: > What description would I get if deference GET oslc:deleteGraph? > > You are proposing using fixed, well known names as syntax to construct > the change operation. Using keywords seems more appropriate. > > - - - - - - - - - - - - > > All changeset proposals need also to deal with deleting bNodes - > > oslc:deleteGraph { > _:b1 dcterms:title "A bad link title"; > rdf:object <http://myserver/mycmapp/bugs/1235>; > rdf:predicate oslc_cm:relatedChangeRequest; > rdf:subject <http://example.com/bugs/2314>; > a rdf:Statement. > } > > in TriG does not delete a triple with property dcterms:title. _:b1 is > label just within the file, and not the resource. On parsing you get > different bNodes each time the file is read. > > What's the proposal here? > > DELETE DATA does not allow bNodes in the data specifically because of > the meaninglessness. > > You may which to consider DELETE WHERE {} which allows named variables > (but not bNodes). DELETE WHERE {} is a shorthand for > > DELETE {template} WHERE {pattern} > > with template=pattern. > > Andy > > On 11/03/13 12:48, Steve Speicher wrote: > > On Sun, Mar 10, 2013 at 3:55 PM, Andy Seaborne > > <andy.seaborne@epimorphics.com> wrote: > >> The use of global names for the actions on the graphs can be avoided by > >> including a manifest in the default graph (the way the global names are > uses > >> is really predicate-like). > >> > >> { <> ldp:insert :g1 ; > >> ldp:delete :g2 } > >> > >> :g1 { ... } > >> > >> :g2 { ... } > >> > >> Andy > >> > > > > Thanks for the feedback Andy. You seem to imply that "global names > > for the actions" is a bad thing, can you elaborate why this is a > > problem and what you propose improves it? I think I know the answer > > but I'd rather not assume. > > > > Thanks, > > Steve > > > >> > >> On 09/03/13 23:34, Ashok Malhotra wrote: > >>> > >>> Hi Steve: > >>> We have PATCH for JSON > >>> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-09 > >>> and PATCH for XML: http://tools.ietf.org/html/draft-wilde-xml-patch-04 > >>> > >>> Wouldn't your proposal be better characterized as PATCH for RDF? > >>> So, we should have the RDF folks look at it. > >>> All the best, Ashok > >>> On 3/9/2013 9:35 AM, Steve Speicher wrote: > >>>> > >>>> We have a number of issues related to PATCH'ing resources: > >>>> ISSUE-12 (closed) Can HTTP PATCH be used for resource creation? > >>>> ISSUE-17 changesets as a recommended PATCH format > >>>> ISSUE-27 Should the PATCH method be used, as opposed to POST with a > >>>> given mime type? > >>>> > >>>> I have drafted something very simple that meets most of OSLC's simple > >>>> use cases that I would like to use as a basis for discussion on a > >>>> model for PATCH [1]. It separates the model from the document (format) > >>>> used mostly. It takes an approach that doesn't require SPARQL Update > >>>> but shows how it can be used. The patch document can be any quad > >>>> format. > >>>> > >>>> Feedback welcome on this independent of usage within LDP as well. I > >>>> realize the proposal is incomplete and apologize for that -- I thought > >>>> there was value in sharing what I have so far. I'm currently working > >>>> on some additional validation of this approach as well. > >>>> > >>>> [1] - http://open-services.net/wiki/core/OSLC-Core-Partial-Update/ > >>>> > >>>> -- > >>>> - Steve Speicher > >>>> > >>> > >>> > >> > > > >
Received on Tuesday, 12 March 2013 14:40:49 UTC