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

[ a couple of typos fixed. sorry]
On 23 Jun 2012, at 14:59, Michiel de Jong wrote:

> On Sat, Jun 23, 2012 at 2:32 PM, Nathan <> 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:
>> 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:
>> Thus, I conclude that the only reason to have acct: and to strap it to
>> 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
> 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 "" at the place of "{uri}" would be incorrect.
> That's why the choice was made to put "" 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/#> .

<> a oauth:Account;
   oauth:accountStr "" .

You want oauth:accountStr to be an inverse functional property that uniquely identifies an
account . 

Essentially oauth:accountStr's inverse is a function from a string to a resource. let's call that 
inverse oauth:account. Then in functional notation we have

  oauth:account("") = <>

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.


so now we can describe a person using foaf via their oauth account using:

  @prefix foaf: <> .

  [] a foaf:Person;
     foaf:account ""^^oauth:account . 

Add a WebID [1] and you could have

 <> a foaf:Person;
      foaf:account ""^^oauth:name;
      foaf:openid <> .   //or wherever google puts its openid

Just some thoughts....


> Cheers,
> Michiel

Social Web Architect

Received on Saturday, 23 June 2012 13:38:43 UTC