- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 04 Jan 2012 10:07:38 -0500
- 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 > 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. -- 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
Received on Wednesday, 4 January 2012 15:12:21 UTC