- 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