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

Re: WebID-ISSUE-64 (redirects): Redirects [WebID Spec]

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 9 Oct 2012 21:47:20 +0200
Cc: public-xg-webid@w3.org
Message-Id: <D5B2FE87-30C7-4451-8721-C349231BBF85@bblfish.net>
To: Kingsley Idehen <kidehen@openlinksw.com>

On 9 Oct 2012, at 20:28, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 10/9/12 1:58 PM, Henry Story wrote:
>> I opened this issue now:
>>   https://www.w3.org/2005/Incubator/webid/track/issues/64
>> Please come up with some text, and help along. It's a difficult issue.
>> We need text for
>>   a- what happens when a redirect moves from http to https  (security section)
>>   b- how to resolve urls in remote documents that were reached by redirects
>>   c- whether the WebID itself changes if redirected???
>>   d- a note on reasonable numbers of redirects to follow and pointer to http spec
>>  I am not sure I have an answer for c.
> If the WebID changes, and there's no inference in play (e.g., owl:sameAS), it has to be invalid. That's the nature of the underlying semantics of this identity verification protocol.

What would be useful would be some justfication for that statement.
An example would help. Take a WebID 


We dereference
which redirects with 303 to
which redirects with 301 to

Does that now mean that 

  http://joe.example/#me owl:sameAs http://joe.org/people/card#me ?

Is there ever a case where that is the case?
Is there any standard we can point to to make our case either way?


>> Henry
> -- 
> 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

Social Web Architect

Received on Tuesday, 9 October 2012 19:48:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:56 UTC