Re: Registration of acct: as a URI scheme has been requested

On 6/24/12 4:42 AM, Melvin Carvalho wrote:
> On 23 June 2012 21:35, Kingsley Idehen < 
> <>> 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.


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


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?

>     -- 
>     Regards,
>     Kingsley Idehen
>     Founder & CEO
>     OpenLink Software
>     Company Web:
>     Personal Weblog:
>     <>
>     Twitter/ handle: @kidehen
>     Google+ Profile:
>     LinkedIn Profile:



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Sunday, 24 June 2012 14:59:47 UTC