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

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

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Wed, 21 Nov 2012 08:08:25 -0500
Message-ID: <CAGR+nnGzq+77Oy1O0+8k3gGi8gshGC7cNW-u-NASTfh=1YJozg@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: "public-webid@w3.org" <public-webid@w3.org>, Kingsley Idehen <kidehen@openlinksw.com>
On Wed, Nov 21, 2012 at 7:55 AM, Henry Story <henry.story@bblfish.net>wrote:

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

you mean IRI right? That was also part of Antoine's feedback to switch from
URI to IRI.

Steph.


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


-- 
Steph.
Received on Wednesday, 21 November 2012 13:08:53 UTC

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