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

On 6/23/12 9:21 AM, Henry Story wrote:
> On 23 Jun 2012, at 14:59, Michiel de Jong wrote:
>
>> On Sat, Jun 23, 2012 at 2:32 PM, Nathan <nathan@webr3.org> wrote:
>>> Michiel de Jong wrote:
>>>> It's a premise of webfinger that we resolve a human-memorable string
>>>> of the form 'user@host' to accounts.
>>> I understand that, but don't see any need for a acct: URI scheme to
>>> accomplish that.
>>>
>>> This is a URI that will accomplish the task:
>>>
>>>   https://gmail.com/.well-known/host-meta?resource=joe@gmail.com
>>>
>>> So where's the need for acct: ?
>>>
>>> This is not two URIs, it's one URI, and no better than the above in any way:
>>>
>>>   https://gmail.com/.well-known/host-meta?resource=acct:joe@gmail.com
>>>
>>> Thus, I conclude that the only reason to have acct: and to strap it to
>>> joe@gmail.com is to use it as an identifier for an account, when that
>>> account already has a perfectly good, stable over time, but not exposed and
>>> non dereferencable identifier of it's own. Hence my previous mail.
>>>
>>> Best,
>>>
>>> Nathan
>> That would in itself work, but it would violate
>> http://tools.ietf.org/html/rfc6415 on which webfinger is based.
>> RFC6415 unambiguously states that the specific resources about which
>> information is retrieved should be identified by their URIs, not by
>> any custom strings. It says additional protocol-specific parameters
>> may be used, but identifying the resource should be done with a URI.
>> Especially in the two-step setup (when resolving an LRDD template),
>> putting "joe@gmail.com" at the place of "{uri}" would be incorrect.
>> That's why the choice was made to put "acct:joe@gmail.com" there
>> instead. There is a reason that resources are identified by URIs and
>> not by per-protocol strings. Namely that if every protocol uses the
>> URI format to refer to resources, then everything becomes more
>> combinable.
>>
>> As i understand it, if the authors of webfinger have tried to change
>> RFC6415 to allow referring to resources with protocol-specific strings
>> that are not URIs, that would be going against the architecture of the
>> web?
> You can do if if you think in terms of relations. Here in Turtle:
>
> @prefix oauth: <http://some.domain.tobedeterined/ont/#> .
>
> <https://gmail.com/.well-known/host-meta?resource=acct:joe@gmail.com> a oauth:Account;
>      oauth:accountStr "joe@gmail.com" .
>
> Here you want oauth:accountStr to be an inverse functional property that uniquely identifies an
> account .
>
> Essentially oauth:nameStr's inverse is a function from a string to a resource. let's call that
> inverse oauth:name. Then in functional writing
>
>     oauth:account("joe@gmail.com") = <https://gmail.com/.well-known/host-meta?resource=joe@gmail.com>
>
> auth:account is a function that takes a string and maps it to a uri. It is a partial function on strings - not all strings will have results. Those that do should have an e-mail address like syntax, and from that string it can construct the url that is the lookup. It turns out that in rdf you can express this using datatypes.
>   
>    "joe@gmail.com"^^oauth:account
>
> so now we can describe a person using foaf via their oauth account using:
>
>     @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
>     [] a foaf:Person;
>        foaf:account "joe@gmail.com"^^oauth:account .
>       
> Add a WebID [1] and you could have
>
>    <http://plug.google.com/joe#me> a foaf:Person;
>         foaf:account "joe@gmail.com"^^oauth:name;
>         foaf:openid <http://plus.google.com/joe> .   //or wherever google puts its openid
>
> Just some thoughts....
>
> [1] http://webid.info/spec/
>
>>
>> Cheers,
>> Michiel
> Social Web Architect
> http://bblfish.net/
>
>
>
>
All good, but the folks interested in Webfinger don't see the world of 
structured data representation in the same manner espoused above. They 
aren't interested in FOAF or anything else that's based on an RDF 
syntax. The don't care about relationships, semantics, and ontologies 
through which they are delivered etc..

In this case we can't force the horse to the river let alone even 
attempt to force it to drink.

We have to embrace choice and options. Eventually, the magic of AWWW 
will bring all of this together, in due course.

-- 

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