Robert Sanderson wrote:
> To abuse an overused quote: "And now you have two problems."
>
> Firstly, you have an additional kitten (URI) to pay for with the
> descriptions resource in addition to the other URIs.
>
> Secondly, the semantics of your descriptions resource are unclear. Is it an
> information resource or not? Is it a conceptual set of all of the formats
> of the descriptions of the original resource? If so, shouldn't it have its
> own description? If it's not that, what is it? If it is, how do you
> negotiate for which format you want the description of the set to be in,
> rather than the item from the set?
disagree (but also get your point and disagree in the nicest way
possible); neither the html document or the rdf are the description. the
description is a different thing entirely which is contained by either
the html document or the rdf document.
/resource/London
rdfs:label "London"@en ;
isPrimaryTopicOf /description/London .
/description/London
primaryTopic /resource/London ;
isPrimaryTopicOf /description/London.html,
/description/London.rdf .
/description/London.html a Document .
/description/London.rdf a Document .
Thus you already always have the /descriptions/London resource.
nb: there is something about justifying the use of /descriptions/London
as a negotiation point in addition to it being the identifier of the
description that is niggling me, i.e. which status code to use and
whether to use content-location or just Location. I am though certain
that just a blog post html page is the primaryTopicOf the sioc:Post, the
rdf and html in this example are the primaryTopicOf the description.
hope this didn't sound too assertive, I am looking for a bit of
discussion / debating about it.
Best,
Nathan
> "Do not multiply entities unnecessarily" also comes to mind.
>
> Rob Sanderson
>
> On Wed, Mar 24, 2010 at 8:11 AM, Nathan <nathan@webr3.org> wrote:
>
>> forgot to mention.. if you have the following urls:
>>
>> http://example.com/resource/London
>> http://example.com/descriptions/London.html
>> http://example.com/descriptions/London.rdf
>>
>> then you can simply enable multiviews for apache and 303
>> /resource/London through to /descriptions/London, and apache handles the
>> rest
>>
>> regards!
>>
>> Nathan wrote:
>>> Hi All,
>>>
>>> After much thought recently I've taken the following approach (please do
>>> negate the fact I'm using .html etc in examples, it's only for clarity
>>> in this email).
>>>
>>> Suppose I have a real world object:
>>> http://example.com/resource/London
>>>
>>> and then an html and rdf description
>>> http://example.com/page/London.html
>>> http://example.com/data/London.rtf
>>>
>>> then I am adding in one more resource to the equation; a resource which
>>> identifies the description; which then acts as the point for content
>>> negotiation. http://example.com/descriptions/London
>>>
>>> Thus:
>>>
>>> REQUEST->>>
>>> GET /resource/London HTTP/1.1
>>> Host: example.com
>>> Accept: text/html;q=0.5, application/rdf+xml
>>>
>>> <<<-RESPONSE
>>> HTTP/1.1 303 See Other
>>> Location: http://example.com/descriptions/London
>>>
>>> REQUEST->>>
>>> GET /descriptions/London HTTP/1.1
>>> Host: example.com
>>> Accept: text/html;q=0.5, application/rdf+xml
>>>
>>> <<<-RESPONSE
>>> HTTP/1.1 200 OK
>>> Content-Location: http://example.com/page/London.html
>>> Content-Type: text/html
>>> (and Vary: etc)
>>>
>>> This way /descriptions/London stays in the address bar and the:
>>> GET /descriptions/London HTTP/1.1
>>> Accept: application/rdf+xml
>>> request that may be used in the future stays good because we've
>>> separated the cross cutting concerns.
>>>
>>> note: it could also be a 300 Multiple Choices + Location header for that
>>> final response.
>>>
>>> This also helps with the wrong uri in the db scenario, because even in a
>>> worst case scenario where /descriptions/London is used rather than
>>> /resource/London then any RDF processor can simply read that
>>> /descriptions/London is a resource which describes /resource/London
>>> rather than being /resource/London itself; a simple bit of reasoning
>>> over isPrimaryTopicOf or similar will fix this.
>>>
>>> Comments / Corrections?
>>>
>>> Regards!
>>>
>>> Richard Cyganiak wrote:
>>>> Hugh,
>>>>
>>>> On 23 Mar 2010, at 22:50, Hugh Glaser wrote:
>>>>> Assuming that we are in the usual situation of http://foo/bar doing a
>>>>> 303 to
>>>>> http://foo/bar.rdf when it gets a Accept: application/rdf+xml
>>>>> http://foo/bar
>>>>> what should a server do when it gets a request for
>>>>> Accept: application/rdf+xml http://foo/bar.html ?
>>>>>
>>>>> OK, the answer is 406.
>>>> No. The answer is 200, with the HTML representation. Content negotiation
>>>> should happen on the â€œgenericâ€