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

On 6/22/12 5:01 PM, Henry Story wrote:
> On 22 Jun 2012, at 22:35, Kingsley Idehen wrote:
>
>> On 6/22/12 1:02 PM, Harry Halpin wrote:
>>> It seems like it would be better to use just mailto: (i.e., the original WebFinger design was around *email addresses*, not accounts per se) or a http: URI rather than mint a whole new scheme.
>> Here's why mailto: won't work. Most user agents will invoke an email client app. Remember, this is about using the URI as a name rather than data locator or access mechanism. That's the reason my acct: is required. Basically, follow-your-nose linked data traversal (with alternative URI resolvers hooked in via host-metadata pattern usage) without unintended consequences i.e., de-reference the next chunk of data etc...
>>
> Yes, though one wonders why they don't just put a URL in there: it could be
>
>     http://google.com/.wellknown?id=joe@gmail.com

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.

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.

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

The a user agent (where URI/URL scheme has been registered with an associated handler) performs de-refrence using:
http://google.com/.wellknown?id=joe@gmail.com  .

The denotation (name) and resource identification indirection is dealt with by the resolver registered with the user agent. The only problem with this is that it isn't as natural as using http: where browser style of user agents already know how to resolve. Net effect, the follow-your-nose pattern works more seamlessly since you don't need special handlers.


> The machine readable url is hidden from view of the user, and the human readable one is a string that the user can read.

But in this case the "human friendly" aspect is more like a natural key 
in an RDBMS table.
>
> I don't think that user will find the "accnt:" string in front of their e-mail in any way intuitive.

Users already find "joe@host" intuitive. That's the whole point. It 
implies: 'Joe' known to some host machine or user 'Joe' on some machine.

Basically: ssh Joe@host means: get me on to said host as user 'Joe' .

User 'Joe' doesn't think in terms of account 'Joe' instinctively.

> And if they were asked to distinguish between that and an e-mail url it would get even more confusing.

The only time email comes into play is if the mailto: scheme is used, 
then via follow-your-nose clicking on a URI (using a browser for 
instance) will result in email app. invocation.
>
> Furthermore the accnt uri then imposes a set of conventions such as .well-known on the web where web architecture tries to avoid such conventions as much as possible - essentially because there is no way to impose such conventions on the whole web.

Yes it does. That's a cost, but costs are not the basis for invalidating 
an idea. The issue here is that we are trying to invalidate an approach 
purely on the basis of costs. Even though http: has its own set of costs 
as demonstrated by the Semantic Web Project odyssey and general 
struggles with Linked Data meme comprehension etc.. Basically, 
httpRange-14 imbroglio whenever the issue of real-world entity 
denotation combined with web resource identification comes into play.

Imagine if all browsers adopted the host-meta patterns and stopped being 
http: scheme specific? At some point in time, this form of user agent 
will decouple from http: as a matter of survival re. trying to remain 
relevant.

BTW -- in the mobile computing realm, URI scheme variety is natural and 
the net effect is more expansive and sophisticated use of the Web.

Linked Data using non http: scheme URIs for denotation while still 
exploiting URLs for Web resource identification and actual data access:

1. 
http://linkeddata.uriburner.com/describe/?url=urn:lsid:ubio.org:namebank:12292 
-- LSID (note what's in About: section of the page re. @href)

2. http://en.wikipedia.org/wiki/LSID -- about lsid: scheme URI from 
Wikipedia (again, this is costly, and http: scheme URIs are more natural 
to the Web) .

Kingsley

>
>
> Henry
>
>> -- 
>>
>> 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
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>
>


-- 

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