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

Re: Should specifications take sides in the httpRange-14 debate?

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 21 Nov 2012 13:55:42 +0100
Cc: Kingsley Idehen <kidehen@openlinksw.com>
Message-Id: <BBCCD90D-51EA-4928-B537-4698E1D2C39F@bblfish.net>
To: "public-webid@w3.org" <public-webid@w3.org>
But there is also Larry Massinter's position
published here: http://lists.w3.org/Archives/Public/www-tag/2012Nov/0024.html

> Speaking for myself:
>  
> I think the TAG taking up this issue was based on the presumption (which I question) that httpRange-14 was an issue that made sense without any additional context, or that, even if the question made sense, that a uniform answer was necessary or feasible.
>  
> if I working group wishes to promote one side or another, let them. There is no reason to imagine the TAG would make more progress in the next 10 years than it has in the last, on this (so-called) issue.
>  
> The design proposed is one where there is a WebID protocol element whose value resembles a URL (not a URI? Surely you are not planning on requiring the non-English world to use ASCII WebIDs?) but is not in fact _any_ URL but rather a string which meets other criteria but also uses the http or https scheme with a fragment identifier. Presumably you will outlaw http://localhost/ or http: URIs which don’t include FQDNs (fully qualified domain names), etc.
>  
> Given that you have a string resembling a URL but not really ‘any URL’, any decision made in such a narrow application is unlikely to be accepted by “other sides” of identifier preferences.
>  
> Larry

I think there Larry makes a good point with regard to URI/URLs. Now that we have 
agreed to restrict to http/https URI's we should use the URI term, as that deals
with internationalisation. 


On 21 Nov 2012, at 13:44, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 11/21/12 6:39 AM, Henry S. Thompson wrote:
>> Work continues within the TAG on this issue [1].  On current course
>> and speed, I expect hash URIs will be just fine.  My personal take on
>> the likely TAG position is that no community of practice with respect
>> to URI use on the Semantic Web can or will be declared to be
>> "losers".  The goal of the current work is to foster interoperability,
>> not mandate a single "winner".
>> 
>> Hope this helps,
>> 
>> ht
>> 
>> [1] http://www.w3.org/2001/tag/products/defininguris.html
> 
> FWIW -- for those of you that want to define a WebID  in a manner that contradicts the position above.
> 
> An architecture spec isn't about optimization. Engineering deals with optimization. A technical spec isn't supposed to teach engineering or shoehorn engineering decisions.
> 
> If anyone is serious about solving this issue. Simply call a vote. I would be really interested to see how many real Linked Data practitioners support the proposal for WebIDs being hash based HTTP URIs while also trying to reconcile that back to TimBL's Linked Data meme as its architectural foundation.
> 
> You don't pick winners (if you can help it), since you ultimately always alienate the losers.
> 
> -- 
> 
> 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
http://bblfish.net/


Received on Wednesday, 21 November 2012 12:56:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:46 UTC