- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 24 Jun 2012 10:59:22 -0400
- To: www-tag@w3.org
- Message-ID: <4FE72B4A.5020205@openlinksw.com>
On 6/24/12 4:42 AM, Melvin Carvalho wrote: > > > On 23 June 2012 21:35, Kingsley Idehen <kidehen@openlinksw.com > <mailto:kidehen@openlinksw.com>> wrote: > > On 6/23/12 2:26 PM, Melvin Carvalho wrote: > > > Kingsley I totally agree that the net is a robust enough > architecture to handle a new scheme, and the axiom of > 'tolerance' more or less guarantees this. But the question at > hand is whether the benefits of a new scheme justify the > overhead involved. > > Let me flip your question around re. http: scheme URIs and Linked > Data. > > Does the unintuitive nature of http: scheme URI based names > warrant the adoption and comprehension overhead that it brings? > Exhibit #1 httpRange-14 imbroglio. Basically, whenever you attempt > to explain the virtues of Linked Data you end up being stymied by > the confusion inherent in http: scheme based names. > > > IMHO http is extremely well designed. I consider it intuitive and > I've not had a problem explaining the web of documents, to NON > technical people, or those that want to learn. Yes, it is extremely well designed. I've never thought otherwise. That doesn't mean there can't be alternatives that co-exist with it when it comes to real-world entity denotation (naming). HTTP is phenomenal for data access. Its counter intuitive (but still extremely powerful) when it comes to real-world entity denotation (naming). Thus, if you are trying to introduce the concept of Web-scale data objects that requires denotation of real-world entities, it isn't so easy to explain. If it was, we wouldn't have the HttpRange-14 imbroglio. > > > The convenience of acct: in undeniable, but is conveniece a > sufficient motivation for creating a Internet level > scheme/protocol. > > > The only solution is choice. Is this the only non http: URI in > existence? > > AWWW is "horses for courses" friendly, so is Linked Data. We > should keep it that way :-) > > > I understand in the spirit of tolerance that a low bar should be set > for new ideas. Always. > > It's very tempting to mint new URI schemes in order to solve technical > problems. Yes, and folks have already done that for years. Most of the time they fade away as the real costs manifest. > People often think that the introduction of a new scheme will solve > all their problems, but in truth, it would take many years or even a > decade of hard work, for a new scheme to gain anywhere near the > traction of mailto: or http:. Even then, it's not guaranteed. Sorta. Remember, you can have [non-http-uri-based-names] that use [http-urls] to resolve to web documents as per Linked Data pattern. There's nothing wrong with that, and it is only artificially costly in a world of http: scheme specific user agents e.g., today's browsers. In the future, applications will use the aforementioned pattern to cost-effectively deliver value since the Web browser is really on its last legs as the primary mechanism for Web value exploitation. > > By logical extrapolation we would also need a user: URI scheme to > define subject of type user, for the next app. Perhaps a thing: URI > scheme for things. And what about machines, will another spec need > agent:? I don't think this is the issue. But assuming this to be the case is the problem re. understanding the thinking behind the acct: scheme URI. Maybe one has to thing about an Internet of Things instead of a World Wide Web of things instead. Or put differently, why does URI abstraction even exist if http: is the only scheme that matters, all of the time. Token acceptance of mailto: is simply due to Internet email preceeding the World Wide Web. > > Kingsley, I do agree with you that tolerance is perhaps the most > important axiom of the web, perhaps also in real life, too. But from > a technical architecture perspective, there is an overhead for adding > a new scheme, and I think it's right for there to be oversight. The overhead of adding new URI schemes exists where? Who bears this burden? Kingsley > > > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > <http://www.openlinksw.com/blog/%7Ekidehen> > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > -- 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 Sunday, 24 June 2012 14:59:47 UTC