Re: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...

On 31 Dec 2011, at 17:17, Peter Williams wrote:

> lets et back to qualifying the spec, as a piece of engineering. Is it mature, is it ready, is it consistent, is it creditable, have the political agendas been removed, does it teach without leading?
> 
> 
> 
> Jurgen told me he expected 2 link to work, when a user enters them on some W3C hosted RDFa.py form, acting as a linked data client. I should enter a URI foo and URI foo#html. He expected triples to be returned from windows web server to the linked data client embedded in a server module, in either case. The only differnece between the 2 cases was presence of #html on the GET on the wire (IE6 like), as emmitted by the W3C server doing server-server communications over HTTP.

Okay, both Kingsley and I have said now — servers accepting fragments in request-URIs is *not* part of the linked data picture. A consumer which does it is buggy and needs to be fixed — in this case, I believe it's a matter of the consuming code just passing the URI verbatim to your server instead of stripping out the fragment as it's meant to.

(The fact that some servers do it doesn’t change this — there’s nothing which says a server CAN'T accept them, just that a client can't send them).

Out of the box Apache doesn't accept them any more than out of the box IIS. Linked Data doesn't require servers to be configured in any special linked-data-specific way (to do so would defeat the point of linked data). 

If you're curious: any server which allows regular-expression-driven rewrites can make it work, just by stripping out a (#.*)?$ portion (and historically this has been easy on Apache and not easy on IIS without third-party tools). However *you should not have to do this*.

> The case the triples MUST be returned in server-server communications with a #fragment on the wire of the GET is what I have learned is termed: "linked data nuances" for web server configuration. 

This is pretty much entirely incorrect.

M.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Sunday, 1 January 2012 16:36:46 UTC