W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

Re: WebID equivalence

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 04 Jan 2012 10:07:38 -0500
Message-ID: <4F046B3A.3070602@openlinksw.com>
To: Dan Brickley <danbri@danbri.org>
CC: Mo McRoberts <mo.mcroberts@bbc.co.uk>, Henry Story <henry.story@bblfish.net>, public-xg-webid@w3.org
On 1/4/12 9:34 AM, Dan Brickley wrote:
> 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

Yes, but I would also like you to share some insights into the 
challenges associated with Linked Data deployment where de-referencable 
URI base Names are for all intents and purposes a luxury, irrespective 
of their intrinsic prowess.

I am trying to remind people here that Linked Data is nuance laced 
albeit powerful. The fact that I have no problem deploying linked data 
with my toolset doesn't make that the norm for others. I am not getting 
this dimension of my message across with success here, each attempt 
starts of a series of long repetitive threads. Thus, I seeking 
alternative voices that also understand (from experience) the *luxury* 
nature of HTTP based de-referencable Names as required by Linked Data.



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
Received on Wednesday, 4 January 2012 15:12:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:54 UTC