Re: Web Identity and Discovery - WebID 1.0

On Wed, Feb 6, 2013 at 4:29 PM, Kingsley Idehen <kidehen@openlinksw.com>wrote:

> On 2/6/13 10:10 AM, Henry Story wrote:
>
>> On 6 Feb 2013, at 15:39, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>>  On 2/6/13 6:39 AM, Andrei Sambra wrote:
>>>
>>>> As promised, I have updated the spec according to the latest poll
>>>> results. I've also cleaned it up a little, mainly fixing inconsistencies
>>>> with some terms.
>>>>
>>>> I would like to ask everyone to take a look and see if everything is ok
>>>> before we move to WebID-TLS.
>>>>
>>>> Here is the link to the latest version: https://dvcs.w3.org/hg/WebID/**
>>>> raw-file/tip/spec/identity-**respec.html<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html>
>>>>
>>>> Best,
>>>> Andrei
>>>>
>>> Why do you still have this warning:
>>>
>>> "Implementers are highly encouraged to use hash URIs for the WebID HTTP
>>> URI. Even though 303 redirects have been used in the past, experience has
>>> shown that they can be difficult to deploy and can have an impact on
>>> performance. However WebID Verifiers must not fail when dereferencing
>>> hashless URIs, though they may flag them as potentially impacting on
>>> performance."
>>>
>>> You don't need that piece of confusion. The examples can be hashed based
>>> and just leave it at that.
>>>
>>> I thought this matter was completely closed based on the vote i.e.:
>>>
>>> 1. A WebID is a HTTP URI
>>> 2. Use hash based HTTP URIs in all examples.
>>>
>> yes, but it is still true that there is a cost for the client and for
>> deployment of non hash based URIs, since they require 1 extra
>> dereferencing: ie. one more connection on the network. The speed of light
>> being limited, this is a cost.
>>
>
> Yes, but doesn't need to be in the spec. People are going to work with
> examples. The examples are the effective route to hash URI utility etc..


I strongly believe that having this notice is very important, since it ties
together fragment identifiers with documents and the fact that #-less URIs
need to rely on 303 redirects. In the end it's just a note, with no impact
on the definition itself, since I've removed the part about verifiers.


>
>
>> I would change the "can have impact on performance" to "have impact on
>> performance".
>>
>> Perhaps "highly encouraged" can be reduced to "encouraged". In any case
>> we need some reason
>> to explain in the spec why the examples are in terms of hash uris.
>>
>
> If all the examples are hash URI based, the mission will be accomplished.
> Just as the whole Semantic Web mission was unaccomplished by the prevalence
> of RDF/XML across all examples produced by the W3C.
>
> Kingsley
>
>
>> Henry
>>
>>
>>> --
>>>
>>> Regards,
>>>
>>> Kingsley Idehen
>>> Founder & CEO
>>> OpenLink Software
>>> Company Web: http://www.openlinksw.com
>>> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
>>> Twitter/Identi.ca handle: @kidehen
>>> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
>>> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>>>
>>>
>>>
>>>
>>>
>>>  Social Web Architect
>> http://bblfish.net/
>>
>>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>