- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 05 Mar 2012 06:42:55 -0500
- To: www-tag@w3.org
- Message-ID: <4F54A6BF.2030109@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 5 March 2012 11:43:26 UTC