Re: quick advice on content negotiation

Toby Inkster wrote:
> On Tue, 2009-12-08 at 16:43 +0000, Nathan wrote:
>> I've implemented content negotiation as follows:
>> where we have a URI resource http://example.org/user/23
>> when that URI is requested then content negotiation using the Accept
>> header kicks in, if any of the RDF formats are specified and data
>> exists then serialized RDF in the requested format is returned;
>>
>> if one of the HTML types is requested then an HTML document
>> (essentially the "page" is returned.
>>
>> in addition adding the extension .n3 / .rdf to the uri causes content
>> RDF to be returned instead.
>>
>> passable and usable? 
> 
> An important question not answered in your message is: what is the URI
> <http://example.org/user/23> supposed to identify?

<http://example.org/user/23> identifies the sioc:User which
sioc:account_of <http://example.org/user/23#person>

the #person data is also included in the reply to a request on /user/23
thanks to using the fragment.

> If it identifies a particular person, then this behavious semantically
> problematic. Why? Because a web server should never respond "200 OK" to
> a request for a URI identifying a person, unless it intends to
> physically chop the person up and pass him/her down the wire to the
> receiving user agent.

as above

> If the URI <http://example.org/user/23> is supposed to identify, say, a
> person's profile, and you have a different URI to represent the person
> themselves (e.g. <http://example.org/user/23#me>) then the connection
> negotiation setup you describe is fine.

as mentioned we use #person (like you said #me); and in the case of html
for profiles the request kicks on to /person/23 which isn't used as a
resource identifier but is the URL of an html page which is the users
profile page.

thanks for the reply toby; taking from this that the setup
aforementioned is okay.

many regards,

nathan

Received on Tuesday, 8 December 2009 17:08:42 UTC