Re: HTTP Range 14

On 3/4/12 5:41 PM, Graham Klyne wrote:
> On 04/03/2012 19:32, Kingsley Idehen wrote:
> > Graham,
> >
> > The problem with new URI schemes is that you can't get browsers to 
> support them.
> > Browsers are the main source of the current problems. [...]
>
> Well,  I wasn't advocating or dismissing any particular solution, just 
> pointing out a similarity with an existing proposal.
>
> As for the browsers being the problem... well, maybe I'm out on a 
> limb, but I happen to believe there's more to the Web than just browsers.

So do I, but I also understand that technology evolution works better 
than revolution. Thus, the innovation has to work transparently with 
what exists. This is why http: scheme URIs are the preferred (but not 
sole) vehicle for Linked Data.

>
> And as for the infrastructure that "just works" - I guess that's true 
> if you don't look too far beyond current capabilities and expectations. 

Yes, if you want to be non disruptive, then you want to show technology 
users how a tweak to the system enables them do more. That always trumps 
"rip and replace" .

> But even there, Jonathan's analysis of the issue points out that, 
> among other things, there is a lack of clarity in the handling of 
> "landing pages" - one that I've run up against but didn't previously 
> recognize as a manifestation of the old "HTTP-range-14" problem.

The lack of clarity is a function of poor narrative. The recommendations 
for httpRange-14 are a collection of options for preserving the essence 
of the WWW architecture and vision.

> Technically, I believe the current muddle can indeed be made to "just 
> work". But the web is more than just a technical system - it's people 
> too. 

If what you said wasn't baked into the architecture of the Web it 
wouldn't exist as the ubiquitous system it is today. It has always been 
a system with dexterous technical architecture. Thus, rather than caving 
in as adoption grows, it has the ability to evolve in non disruptive 
ways. We've moved from binding networking, hyperlinks, and structured 
documents to doing the same for networking, hyperlinks, structured 
documents, and structured data. That's quite an uncommon feat with 
regards to software oriented technology architecture.

> And I think there are times when what people expect diverges from what 
> the technology delivers, leading to outcomes that may be technically 
> correct, but not useful in the sense of not meeting people's expectations.

People just want to click-click-click, and in doing so, 
follow-their-noses en route to a journey that's increasingly laden with 
serendipitous discovery . This is what they truly seek of the Web medium.

>   If we can find a narrative that makes better sense of the present 
> technical architecture, which I think Jonathan's recent postings could 
> lead towards, then that will be great.

Yes!

We need to fix the narrative. Now, that doesn't mean rejecting existing 
recommendations. It actually means aligning the narrative with what 
exists in other realms. This will trigger the kind of instinctive 
juxtaposition that isn't happening right now. For instance, anyone 
grappling with "Open Database Connectivity" (ODBC) shortcomings should 
instinctively recognize the alleviation delivered on a platter by Linked 
Data.

>   But until then, I won't completely close my mind to alternative 
> solutions, even if that means additional URI schemes.

We have to deliver a non disruptive evolution rather than a disruptive 
revolution. Browsers are critical parts of the ecosystem. We can't 
eradicate them just like that :-)

Kingsley
>
> #g
> -- 
>
> On 04/03/2012 19:32, Kingsley Idehen wrote:
>> On 3/4/12 1:58 PM, Graham Klyne wrote:
>>> Hi Chris,
>>>
>>> Your infra: looks a bit like tdb: [1]. I believe Larry's currently 
>>> aiming for
>>> "experimental" publication so folks can reasonably try it out on the 
>>> open web.
>>
>> Graham,
>>
>> The problem with new URI schemes is that you can't get browsers to 
>> support them.
>> Browsers are the main source of the current problems. For instance, 
>> Linked Data
>> (where http: scheme URIs serve as names for any 
>> description/descriptor document
>> subject) enables browsers effectively play the role of "drill-down" 
>> and "pivot"
>> oriented clients via the follow-your-nose pattern courtesy of 
>> de-referencable
>> http: scheme URIs.
>>
>> As stated in my earlier response, we are practically moving from 
>> "open database
>> connectivity" to "open data connectivity" where the likes of ms 
>> query, access
>> crystal reports etc.. work transparently against Linked Data graphs 
>> exposed by
>> http uris. In addition, you have the benefit of every browser being the
>> equivalent of: ms access, ms query, crystal reports etc..
>>
>> The importance of this transparent integration of the Web into the 
>> broad realm
>> of "open data access" all depends on http: scheme uris as outlined in 
>> the
>> fundamental architecture of the Web.
>>
>> If people don't understand this, then we can double up effort making 
>> narratives
>> clearer. What we shouldn't do is meddle with architecture and 
>> infrastructure
>> that "just works".
>>
>> To conclude, new uri schemes don't fix the problem at hand. 
>> Conventional web
>> browsers are the fundamental problem.
>>
>> Kingsley
>>>
>>> #g
>>> -- 
>>>
>>> [1] http://tools.ietf.org/html/draft-masinter-dated-uri-10
>>>
>>>
>>> On 04/03/2012 17:37, Christopher Gutteridge wrote:
>>>>
>>>> I've started sketching some ideas I've been thinking about for some 
>>>> time into a
>>>> blog post;
>>>> http://blogs.ecs.soton.ac.uk/webteam/2012/03/01/firing-range-14/
>>>>
>>>> I can turn it into something more formal if there's any positive 
>>>> feedback.
>>>>
>>>
>>>
>>>
>>
>>
>
>
>


-- 

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