W3C home > Mailing lists > Public > www-tag@w3.org > March 2012

Re: HTTP Range 14

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 05 Mar 2012 06:42:55 -0500
Message-ID: <4F54A6BF.2030109@openlinksw.com>
To: www-tag@w3.org
On 3/5/12 1:52 AM, Christopher Gutteridge wrote:
>
>
> On 04/03/2012 22:41, Graham Klyne wrote:
>> 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.  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.  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.  But 
>> until then, I won't completely close my mind to alternative 
>> solutions, even if that means additional URI schemes.
>>
> I agree. The current design is verbose and unintuitive. Using an 
> address with the Hypertext Transfer Protocol to identify real-world 
> things works OK, but it's very counter-intuitive. People on this list 
> have no confusion about URI/URL but every new person trying to learn 
> this stuff, does.
>
> The tdb: protocol doesn't break anything. It aids linking by making it 
> easy to use canonical pages to identify things. A web browser doesn't 
> need to support it -- most of things in question won't be resolvable 
> because they are things.

We are trying to resolve the description of things. Not the things 
themselves. The aforementioned descriptions are delivered by RDF 
documents (resources). The "things" in  question are just the subjects 
of the descriptions -- descriptor documents which are a kind of Web 
resource.

> Sure, a 303 can get you to a data page or HTML page, but that's even 
> more confusing. 

It isn't. Not when you understand (or accept) the fact that the HTML 
document is but one document format for delivering subject descriptions.

> Most web programmers don't grok content negotiation. 

True.

> Our goal really should be to start having linked data produced by the 
> masses of people who know a bit of PHP.

Huh? And what about those programmers that don't care about PHP? Kinda 
strange argument for a system that is fundamentally about platform 
independence across the entire tech stack.

> I believe the reason we still haven't seen the network effect kick-in 
> for linked data is that it's too hard for people who don't care as 
> much as early adopters do. It's got to be achievable by busy people 
> who just skim the instructions.

No, the only reason why the network effect of Linked Data has sorta 
stalled (a bit) is because there was a strange decision to force RDF 
into the narrative -- as a mandatory component -- thereby inheriting all 
of its distractions from the past.
>
> My personal success criteria is when the main topic of discussion is 
> how to deal with spammers trying to inject triples into trusted data 
> sources.

My person success criteria is when end-users and developers that are 
already comfortable with "Open Database Connectivity" (ODBC)  
instinctively realize that Linked Data is really the next step i.e., the 
final deliverance of platform independent "Open Data Connectivity" . 
This will all pan out by them realizing that the concept of a "Data 
Source Name" (DSN) is now effectively delivered via a hyperlink.

>
>
>


-- 

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







Received on Monday, 5 March 2012 11:43:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:43 UTC