W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

Re: New ResourceMe Version

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sat, 07 Jan 2012 14:15:40 -0500
Message-ID: <4F0899DC.3030607@openlinksw.com>
To: public-xg-webid@w3.org
On 1/6/12 7:46 PM, bergi wrote:
> 'HTTP/1.1 303 See Other
> Server: Virtuoso/06.03.3131 (Linux) x86_64-generic-linux-glibc25-64  VDB
> Connection: close
> Date: Sat, 07 Jan 2012 00:11:48 GMT
> Accept-Ranges: bytes
> TCN: choice
> Vary: negotiate,accept
> Content-Location: sioc.rdf
> Content-Type: application/rdf+xml
> Location:http://kingsley.idehen.net/dataspace/raw/person/sioc.rdf
> Content-Length: 0


Here is an explanation of the above, also see the HTTP response code 
page from Wikipedia [1] for reference also note the URI debug URL [2] 
below re. the descriptor resource that has URL: 
http://kingsley.idehen.net/dataspace/person/kidehen .

Content-Location --- reference for an alternate location for the 
returned data
Location --- used in redirection, or when a new resource has been created.

URL: http://kingsley.idehen.net/dataspace/person/kidehen isA resource 
address, representation is negotiable. Thus, you have two paths to the 
representation you seek depending on whether your client thinks in terms 
of Content-Location or redirection oriented Location re. header responses.

For WebID, what's important to you is the location of the composite key 
comprised of WebID and Public Key components that enables "mirrored 
claim" triangulation. How you get to the graph shouldn't matter. It the 
composite key lookup or failure that should determine success or failure.

At the end of the day you are looking for a signed claim match :-)



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

Received on Saturday, 7 January 2012 19:16:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:29 UTC