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

On 6/23/12 3:34 PM, Henry Story wrote:
>> Because, that's forcing the issue re. http: scheme URIs. Again, being an optimal solution isn't the basis for a futile mandate.
>> >
>> >Goal: URI based Linked Data. Basically, achieving Linked Data without http: scheme URI specificity. It can be done, and this is what the likes of Webfinger enable via acct: scheme URIs.
> But there is already a problem: should it be linked to an http or https URL?
> If it is only http, then there can be man in the middle attacks, changing information along the way. So that they soon will need an acctSec: scheme too.

I don't really get that point. URIs are just URIs. Systems will use them 
differently.

>
>> >
>> >Give folks choice. We've already burnt years trying to force a RDF syntaxes on folks, now we are repeating the same thing with URIs. The conceptual framework of a system must always be distinct from implementation components. http: scheme URI, RDF syntaxes etc.. are components used to implement a specific system. Their cost-effectiveness is not the basis for eliminating alternative approaches.
>>> >>
>>> >>or whatever. All the accnt: url is is a short cut for something like the above, because inevitably the account URI has to be resolved in some way such as that. The confusion comes from not being able to distinguish between human readable names and uris.
>> >
>> >The issue is: human oriented natural keys (acct: scheme names) vs one synthetic (system generated) alternative (http: scheme names) that's natural to the host system, in this case the World Wide Web.
> accnt:joe@bblfish.net  is not human understandable.

I didn't say: acct:joe@bblfish.net was human understandable.

I am saying, as system and its promoters can tell explain: 
acct:joe@bblfish.net as an identifier which much more ease than: 
http://bblfish.net/joe#this . The latter implies data access, but naming 
doesn't mandate data access, its only de-referenable naming (key 
functionality) that requires name (denotation), indirection, and data 
(resource) access packed into a name.

> It clearly comes from people who already know about URIs, markup, standards and such like.

The system generates that. This systems need end-user adoption. Adoption 
requires some conceptual introduction, overtly or covertly.

>   What people are going to pass to each other on post cards will be much simpler things likejon@smith.net  

Yes, and the postcard system will know what to do the the URI in question.

>
> The accnt thing is not simple enough, and it is not even secure.

I don't get the point re. security. The is no such thing as an 
inherently secure or insure URI scheme. That's a system attribute.

>   It requires people to adopt a pattern of publishing information on their web servers, which few other standards require.


End-users don't directly administer HTTP servers. They do so indirectly, 
by working with systems the include HTTP server functionality.

BTW -- you can deploy Linked Data via Google Drive, SkyDrive, DropBox 
etc.. And when they add proper mime type handling, the notion of direct 
HTTP server interaction will move further away from end-users :-)

Kingsley
>
>> >
>>> >>
>>> >><a href="http://google.com/.wellknown?id=joe@gmail.com">Joe@gmail.com</a> is the way we usually differentiate between human readable names and URLs.
>> >
>> >Why not?
>> >
>> ><a href="acct:joe@gmail.com">Joe</a> .
> who is writing this? My grandmother? Clearly not! Whoever can edit this knows about URLs and html and can therefore write thehttp://  version above, which requires a lot less conventions. Just point to the document you want to click on it, and see if it works. It functions in every existing browser, requires no updates to all the libraries to handle it, and is even much more natural to understand.
>
>> >


-- 

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