On 3/25/13 4:42 AM, Mo McRoberts wrote:
On Sun 2013-Mar-24, at 17:39, Kingsley Idehen <[email protected]> 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.
Yes-ish. I say so that because you are correct with regards to the excerpt above. That said, here's an excerpt (further down in the note) that does hone into the matter that's challenged hashless HTTP URI based entity denotation for some time now re., Linked Data:
"If Content-Location is included in a 2xx (Successful) response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims that the URI is an identifier for a different resource corresponding to the enclosed representation. Such a claim can only be trusted if both identifiers share the same resource owner, which cannot be programmatically determined via HTTP."
Basically, the role of the Content-Location header with regards to Linked Data URI disambiguation heuristics is now much cleaner.
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!
Anything to do with Trust ultimately lays the foundation for WebID and WebID+TLS value proposition comprehension and appreciation :-)
-- 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
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________ Dbpedia-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
