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

Kingsley Idehen wrote:
> On 6/23/12 9:42 AM, Nathan wrote:
>> So rather than creating an unstable pretty much useless URI for use 
>> internally within a specific protocol, why not take advantage of this 
>> provision and define the variable {acct} instead, such that you can do:
>> That way you tie in with web architecture, don't need a new 
>> URI-scheme, and still get to do what's required. 
> In what context is any URI useless? Please remember URI abstraction re. 
> context of my question.
> Again: , is a 
> URL, a data access address. Webfinger folks don't want to present: 
> <> as a name 
> to its end-users and developers when they use: <> .
> In a nutshell, you are implying that Linked Data is only achievable via 
> http: scheme URIs. That simply isn't true. Even worse, you are making 
> your case using host-meta which is all about delivering a generic 
> resolver mechanism for URIs. Basically, decoupling the name/access 
> functionality that's baked into http: URLs.
> Being convenient and cost-effective doesn't make http: scheme URIs the 
> sole option for Linked Data. It just doesn't.

As you know I don't need convinced of the benefits of linked data, but I 
would like convinced that the acct: scheme is required; so far I've not 
seen any evidence of this, other existing techs can do the job, and 
RFC6415 appears to cover the cases where identifiers aren't URIs.

I do accept though that saying a URI is useless is was far to strong, 
what I meant to say, or imply, was that creating a new scheme when not 
required may not be the best path to take - which I had thought was the 
point of this thread, and thus discussed then offered an alternative.

WebFinger is valuable, to the web, and the web of linked data, and I'd 
be keen to see it get to where it needs to be with as little red tape 
and limitations possible, if acct: can be swapped out for ?acct= without 
it impeding functionality, and speed up the process, then that's what 
I'd personal opt for.

Best as always,


Received on Saturday, 23 June 2012 19:13:53 UTC