On Mon, Mar 25, 2013 at 9:42 AM, Mo McRoberts <mo.mcrobe...@bbc.co.uk> wrote:
> On Sun 2013-Mar-24, at 17:39, Kingsley Idehen <kide...@openlinksw.com> wrote:
>
>> All,
>>
>> Here is a key HTTP enhancement from Hypertext Transfer Protocol (HTTP/1.1):
>> Semantics and Content note from IETF [1].
>>
>> "
>> 4. If the response has a Content-Location header field and its
>> field-value is a reference to a URI different from the effective
>> request URI, then the sender asserts that the payload is a
>> representation of the resource identified by the Content-Location
>> field-value. However, such an assertion cannot be trusted unless
>> it can be verified by other means (not defined by HTTP).
>> "
>>
>
>
> It's good to have the clarification (the wording in the new draft is nicer),
> but it's probably worth stressing that Content-Location isn't at all new, and
> this *mostly* amounts to a tidying-up of wording rather than a change in
> semantics.
>
> Section 14.14 of RFC2616 (HTTP/1.1) states:
>
> “The Content-Location entity-header field MAY be used to supply the resource
> location for the entity enclosed in the message when that entity is
> accessible from a location separate from the requested resource's URI."
>
> The biggest change here is actually the “However, such an assertion cannot be
> trusted..." part!
>
> M.
>
TimBL's proposal 25 was about introducing a new header (e.g.,
"Document:") with the semantics that I believe are being discussed
here.
At that time, I asked him about the relation between Content-Location
and Document [1]:
On Sun, Apr 1, 2012 at 5:14 PM, Tim Berners-Lee <ti...@w3.org> wrote:
>
> On 2012-03 -29, at 18:26, Erik Isaksson wrote:
>
>> Would the Document header be sort of a strengthened version of
>> Content-Location, with the difference that the returned representation
>> is not a "representation of the target resource" (i.e., probe URI)?
>
> Yes, exactly.
> I though if using Location: but hadn't checked that there wasn't any way in
> which this use
> would clash wit the normal use of "Location:".
Quote from further down in Hypertext Transfer Protocol (HTTP/1.1):
Semantics and Content [2]:
" o For a response to a GET or HEAD request, this is an indication
that the effective request URI refers to a resource that is
subject to content negotiation and the Content-Location field-
value is a more specific identifier for the selected
representation."
So Content-Location provides a "more specific identifier", which I
don't think helps us with avoiding 303. Anyway, personally, I think
we're along the right track here.
Best regards,
Erik
[1] http://lists.w3.org/Archives/Public/www-tag/2012Apr/0009.html
[2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#page-16
>>
>> Implications:
>>
>> This means that when hashless (aka. slash) HTTP URIs are used to denote
>> entities, a client can use value from the Content-Location response header
>> to distinguish a URI that denote an Entity Description Document (Descriptor)
>> distinct from the URI of the Entity Described by said document. Thus, if a
>> client de-references the URI <http://dbpedia.org/resource/Barack_Obama> and
>> it gets a 200 OK from the server combined with
>> <http://dbpedia.org/page/Barack_Obama> in the Content-Location response
>> header, the client (user agent) can infer the following:
>>
>> 1. <http://dbpedia.org/resource/Barack_Obama> denotes the real-world entity
>> 'Barack Obama' .
>> 2. <http://dbpedia.org/page/Barack_Obama> denotes the Web Document that
>> describes real-world entity 'Barack Obama' -- by virtue of the fact that the
>> server has explicitly *identified* said resource via the Content-Location
>> header .
>>
>> Basically, the Toucan Affair [2][3][4] has now been incorporated into HTTP
>> thereby providing an alternative to 303 redirection which has
>> troubled/challenged many folks trying to exploit Linked Data via hashless
>> HTTP URIs.
>>
>> Implementations:
>>
>> As per my comments in the Toucan Affair thread, our ODE [5] Linked Data
>> client has always supported this heuristic. In addition, I am going propose
>> implementing this heuristic in DBpedia which will simply have the net effect
>> of not sending a 303 to user agents that look-up URIs in this particular
>> Linked Data space.
>>
>> Linked Data Client implementation suggestions:
>>
>> I encourage clients to support this heuristic in addition to 303 with
>> regards to Linked Data URI disambiguation. Implementation costs are minimal
>> while the upside extremely high re., Linked Data comprehension,
>> appreciation, and adoption.
>>
>> Links:
>>
>> 1. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#page-15 .
>> 2. http://blog.iandavis.com/2010/11/04/is-303-really-necessary/ -- Is 303
>> Really Necessary post by Ian Davis.
>> 3. http://lists.w3.org/Archives/Public/public-lod/2010Nov/0090.html --
>> mailing list thread .
>> 4.
>> http://linkeddata.uriburner.com/about/html/http/iandavis.com/2010/303/toucan
>> -- example of heuristic handling .
>> 5. http://ode.openlinksw.com -- ODE Linked Data consumer service,
>> bookmarklets, and cross-browser extensions.
>> 6. http://bit.ly/YxW21k -- Illustrating Semiotic Triangle using DBpedia's
>> Linked Data URIs .
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>
>
> --
> Mo McRoberts - Analyst - BBC Archive Development,
> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
>
>
>
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------
>
