Re: WebID equivalence

On 4 January 2012 15:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 1/4/12 6:39 AM, Mo McRoberts wrote:
>> What's (still) not clear is why you'd bother exposing your e-mail address
>> to the world in your certificate when you can have a URI to your WebID
>> profile anyway.
>
>
> Because, and I've said this to you before in a prior post, there are times
> when you need to remember Names. There are times when lookups will fail or
> be unavailable to you. Typical example: when constructing WebID ACLs for a
> resource (e.g. a photo you want to share with members of a group/circle).
> Everyone has been taught to remember and use Email Addresses as Identifiers
> of the Name variety.

There is reasonable evidence from OpenID deployments that users are
more comfortable with email-style identifiers than with http:// URLs.
Hence WebFinger etc. It's less clear how deep into the protocol this
choice should go.

>> Kingsley, you’ve said that you perceive a “bias towards HTTP”, and that’s
>> probably *implicitly* true to an extent: while you could do a lookup against
>> a public LDAP server instead (it's what PGP does, after all), do you not
>> think that most people will end up publishing their profile document via
>> HTTP?
>
>
> They more than likely would, but we don't have to force them to do that per
> se. The bigger problem, as outlined above, is that Linked Data deployment is
> nuance laced and basically a luxury item for the majority. This matter re.
> Linked Data isn't new, what's interesting right now is that in this
> particular use-case there is an opportunity to alleviate this cost.
>
>> And thus, any additional indirection — which isn’t by any means prohibited
>> by the spec — amounts additional complication which really just has novelty
>> value right now… or is there some really compelling justification?
>
>
> I hope I've explained the justification above. Ultimately, there is a Linked
> Data challenge for publishers re. de-referencable HTTP URI based Names. It's
> this very problem that Hammer Stack folks have addressed via Webfinger as a
> vehicle for de-referencable mailto: and acct: scheme URIs. Even in the
> Linked Data realm, you have the emergence of the .well-known/host-meta
> resource as mechanism alleviating costs associated with Linked Data
> deployment.

If I remember correctly, those advocating for WebFinger style
email-shaped IDs, eventually moved away from proposing acct: URIs.

> If for whatever reasons you still don't accept or may understand what I am
> trying to articulate re. Linked Data deployment costs and challenges. I
> strongly encourage Dan Brickley to step in and explain in his own words. He
> has experienced these challenges first hand during the course of his FOAF
> endeavors, over the years.

Not sure how I can help here, other than encouraging you all to see
the best in each other's intentions and find a way to deal with the
different styles and motivations we have in this group.

One broad lesson from FOAF, is that where there are huge repositories
of real people's data, there will always be complex barriers to
accessing it. Commercial, privacy, and so on; the actual data format
aspect is the relatively easy bit. When we're talking about millions
of records, that's incentive enough to parse any file format. WebID
maybe changes the landscape there a bit, but the picture is still far
from clear.

FOAF always had a split personality: one side was about describing a
Web of people; the other side ('rdfweb') was about deploying a Web of
inter-linked RDF files. For the Web of people side, I've lately felt
it more productive to focus on the kinds of data that flow more freely
in the Web. So historical data, publically agreed, not-secret data,
bibliographic networks, people who died 100 years ago, govt org
charts, graphs of collaborations (bands, films, writing, ...), key
signatures,  etc etc. If we can tell that part of the larger public
human story in a compelling way with data linking techologies, it
might help motivate consumers to want (some of) their data to be able
to plug into that historical Web...

Dan

Received on Wednesday, 4 January 2012 16:28:11 UTC