Re: next steps on http graph store protocol

On 2012-01-08, at 17:48, Andy Seaborne wrote:
> 
> 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.

Yup, our systems do that for e.g.

- Steve

>> 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
> 

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Monday, 9 January 2012 11:13:37 UTC