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

On 6/23/12 6:49 PM, Nathan wrote:
> Kingsley Idehen wrote:
>> On 6/23/12 3:12 PM, Nathan wrote:
>>> 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:
>>>>>
>>>>> https://gmail.com/.well-known/host-meta?acct=joe@gmail.com
>>>>>
>>>>> 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: https://gmail.com/.well-known/host-meta?acct=joe@gmail.com , 
>>>> is a URL, a data access address. Webfinger folks don't want to 
>>>> present: 
>>>> <https://gmail.com/.well-known/host-meta?acct=joe@gmail.com> as a 
>>>> name to its end-users and developers when they use: 
>>>> <acct:joe@gmail.com> .
>>>>
>>>> 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.
>>
>> The net effect of creating an new URI scheme could be costly in some 
>> context (e.g. today's World Wide Web dominated by one type of user 
>> agent, the Web Browser). Not necessarily so re.,  other contexts.
>>
>>>
>>> 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.
>>
>> Here's how I've used acct: (since I first encountered Webfinger) for 
>> both WebID and my Profile data in general:
>>
>> 1. http://bit.ly/KtaGwI -- searching on my acct: scheme URI
>> 2. http://bit.ly/MEqals -- full profile
>> 3. http://bit.ly/KFeYG3 -- looking at inverse functional property 
>> effects on co-references
>> 4. http://bit.ly/KTWCCx -- ditto but via explicit co-reference via 
>> owl:sameAs relationships.
>
> I commend your use of URIs, however I still can't see what clear 
> utility the proposed 'acct:' scheme brings to the broad internet 
> community, beyond that which is already available.

Its utility is all about delivering an intuitive URI based name 
(denotation) mechanism based on the familiar email address pattern. 
Email Addresses are commonly used on the Web as personal identifiers. 
Most end-users don't see their identities and their accounts as being 
distinct.

What's the utility of an http: scheme URI assuming a non ubiquitous Web 
or a Web where user agents didn't support this URI scheme by default?

My point remains the same, the issue here is one of perceived and actual 
adoption costs. Those aren't reasons for invalidating use of alternative 
URI schemes.

We shouldn't make choices for people. It always better to present 
choices en route to letting them choose. In due course, the best 
solution wins out.

There will come a day or reckoning for the 12+ year odyssey on the 
Semantic Web vision. When that day arises, I am extremely confident that 
most will realize that this was the ultimate example of how a great 
thing can go awry when its implementation infrastructure is delivered as 
a mandate rather than a choice .

>
> What requirement is fulfilled by the 'acct:' scheme that isn't already 
> handled by other schemes?
> What does it enable, or what is gained by it's use?
> What other techs might it make possible?
>
> If there is a real gap for a scheme which can be used to mint 
> identifiers for the class of things which are user accounts, then 
> shouldn't that need be looked at closely and it be determined whether 
> the scheme specification is open and robust enough to stand the test 
> of time?
>
>  acctURI      =  "acct:" userpart "@" domainpart
>
> This seems very limited, if acct: is to be rolled out at internet 
> level, then why not open it up more, certainly acct:twitter.com/webr3 
> may be useful, are fragments useful, how many of these questions have 
> been looked at, and how deeply has this new scheme been considered 
> beyond the very specific use case it's been designed to work for/around?
>
> I'm not trying to knock or stall anything here, just to nudge towards 
> the notion that it may be either (a) unneeded, or (b) needed and 
> possible to improve/generalise to add even more utility.

It might be subjectively unneeded but lets leave folks to make their 
choice about such matters. I am sure you recall that RDF (once a syntax 
inextricably bound to a model -- due to poor messaging) was also 
mandated for the Semantic Web, then for Linked Data, and the end result 
has been nothing but artificial inertia with regards to escape velocity .

Cost effectiveness is a subject thing too. Thus, it can never be the 
basis for invalidating something that's subjectively useful.

There only thing that I can attest to objectively (in my world view)  is 
the utility of URIs. That's about it :-)
>
> Best,
>
> Nathan
>
>
>


-- 

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