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

On 23 June 2012 19:58, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> 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<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<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<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/#<http://some.domain.tobedeterined/ont/#>>
>> .
>>
>> <https://gmail.com/.well-**known/host-meta?resource=acct:**joe@gmail.com<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<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..
>

I would agree with this assessment in general, however is not true in all
cases.  For example OStatus, which is the one of the major adopters of
Webfinger mentions FOAF in their spec.  Also status.net, one of the major
implementors and authors of that spec, expose FOAF data.  Case in point,
Andrei Sambra, "my profile" [1] is currently doing a friend integration
with status.net based on structured FOAF data.

Kingsley I totally agree that the net is a robust enough architecture to
handle a new scheme, and the axiom of 'tolerance' more or less guarantees
this.  But the question at hand is whether the benefits of a new scheme
justify the overhead involved.

The convenience of acct: in undeniable, but is conveniece a sufficient
motivation for creating a Internet level scheme/protocol.  If so, you could
make the same argument in a number of other cases and specs.  For example,
should we have also a user: URI?  What about the law of independent
invention, and if another spec wants to use something like accnt: to
indicate URI's of type account.  How about URL shorteners, wouldnt it be
possible to argue that there is utility in creating a new scheme for some
shortener patterns (which is similar to this case).  What about new specs
that would like a new scheme?

I'm not saying it's wrong to do, but the cost benefit analysis will need to
be weighed by whoever makes that decision.  It should be noted that not
everyone in the webfinger community is in favor of the acct: scheme.
Webfinger can be done without acct.  It's simply a question of whether the
advantages outweighs the overhead.  I'm sure this will be weighed
carefully, and either outcome should be manageable, imho.

[1] https://my-profile.eu/


>
> 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<http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>