- From: Andy Seaborne <andy@apache.org>
- Date: Wed, 11 Sep 2013 09:26:55 +0100
- To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- CC: "public-ldp-patch@w3.org" <public-ldp-patch@w3.org>
On 11/09/13 07:43, Pierre-Antoine Champin wrote: > Hi, > > I finally nailed what bothers me with relying on bnode labels for PATCH > : either > > 1/ the server exposes its own internal identifiers; this practically > makes thoses internal bnodes into some kind of URI, so why not bite the > bullet, and require the server to skolemize all bnodes for them to be > PATCHable. Note that this bans the use of [] of () syntaxes. > > 2/ the server keeps track of the bnode labels associated to the > *serialization* it served -- this tastes strongly of state-full > connection to me (granted, the serialization is not specific to each > client, but still...). > > Andy's remark, however, gave me an idea: > > On Sun, Sep 8, 2013 at 7:40 PM, Andy Seaborne <andy@apache.org > <mailto:andy@apache.org>> wrote: > > RDF needs first class lists, and sets, data values, not triple-encoded > structures. The encoding eventually shows through - if nothing else > { ?s ?p ?o }. > > > Well, the problem is, we are stuck with RDF as it is, without > first-class lists. > However, why not make them first-class citizen *of the PATCH language* ? > The client would not have to bother with intermediate bnodes, > it would send a high level intention to the server that would convert it > to triple operations... > > Just an idea, though; I have no concrete proposal at the moment. > pa It's a nice idea and if *-patch addresses lists at all, it need onbly address well-formed ones. There is still a need for the server to create new bnodes. We need it both ways round here - refer to existing bnodes and have server-side control of new labels! Skolemization, whether via what RDF-WG proposes or a moral equivalence (a new node type that is the bnode and it's label e.g. _[label] -- more compact), for referring to existing bnodes and _:a, [] and () cause new bnodes. Andy
Received on Wednesday, 11 September 2013 08:27:25 UTC