Re: naming resources - Slug-Header

>>> 
>>>> On 8 Jan 2013, at 11:54, Roger Menday <roger.menday@uk.fujitsu.com>
>>>> wrote:
>>>>> An alternative proposal might be to just take the rdfs:label (or maybe
>>>>> from list of established vocab for 'labels') from the POSTed body as a
>>>>> 'hint' for a name (?)
>>>> That seems to be a compatible proposal.
>>> Well, as soon as you have two ways of doing the same thing, you end up
>>> dealing with conflicts (setting precedence, be sure that a client that
>>> uses only RDF is not ignoring the SLUG header etc...). It is far better
>>> to
>>> avoid that kind of duplicates.
>> 
>> +1; anything that can be handled on the protocol level should be handled
>> on the protocol level. falling back to content sniffing should only be
>> done in those cases where we cannot properly expose interaction semantics
>> through HTTP mechanisms. so my vote goes to adopting Slug, and using this
>> as the only mechanism.
>> 
>> cheers,
>> 
>> dret.
> 
> I prefer the Slug mechanism but for a different reason.
> 
> The body of a request is the desired state of the target.  It is not a 
> description of the request itself but the final state of the resource. 
> "<> rdfs:label" is about the resource.  So I don't know what the subject 
> of the rdfs:label would be.  I think rdfs:label is use for other things 
> (display labels).

So when I said rdfs:label, I wasn't entirely sure if this was the most appropriate predicate we could re-use. What I meant was some existing predicate which means "short name" ... ? 

Regarding your "the body of the request is the desired state of the target" statement. This revisits discussions a few months ago - about creation. I like the idea that predicates of the "request", are just seeds or parameters to a server process which creates one (maybe more) server resources. These are not just copied across from request to created resource. 

thanks, 
Roger