Re: next steps on http graph store protocol

On 07/01/12 04:29, Sandro Hawke wrote:
> On Fri, 2012-01-06 at 12:50 -0800, Gregory Williams wrote:
>> On Jan 6, 2012, at 12:43 PM, Sandro Hawke wrote:
>>
>>> We debated that, but Eric and I, reading 2616 felt like it made sense to
>>> name it after the class of resources called out in the spec, which uses
>>> the term "append".   Of course, for RDF, Append means Merge, but we were
>>> thinking the RDF case doesn't need it's own name for this.
>>
>> Well… My point was that for RDF, it needn't mean merge. I can imagine a trivial service that actually did append n-triples or turtle content, which would yield a non-merge w.r.t. any shared blank node IDs in the POSTed content and the resource being POSTed to.
>
> True.
>
> Hrm.
>
> It would sure be nice to have that option -- doing union instead of
> merge -- wouldn't it?   Of course, that wouldn't work with blank nodes
> that don't even have local labels, but if they had local labels, it
> would be nice to be able to use them.   I wonder why we should forbid
> that?

Er - won't that invalidate the way RDF is parsed?

Note that systems do not necessarily retain the blank node label - it's 
scoped to the file, and after parsing, most systems have some internal 
id, forgetting the original in the file.

>  I guess it's nice for the server to be able to change bnode
>   labels, in theory, at least.

It's a necessity - parse the same file twice and you must get different 
bNodes.

> Anyway, you make a good point; I'm fine with "Merge" (eg
> http:PostMeansMerge or post:MergeResource)  instead of "Union" or
> "Append" for this.
>
>     -- Sandro

 Andy

Received on Sunday, 8 January 2012 17:49:33 UTC