[foaf-protocols] WebID Incubator Charter draft

peter williams home_pw at msn.com
Thu Dec 16 20:33:59 CET 2010


Folks have been focusing on the construct of a “webid *protocol*” . I think that this was a refinement (and/or just a plain renaming) of what we used to discuss as FOAF+SSL. If it’s a refinement, its one that allowed use to specifically go above and beyond both FOAF and SSL (as we came to know them, in https refs to FOAF docs). It includes what started this whole process 2 years ago (how would openid be done, if using only semweb techniques), but has grown up and beyond that to address the web in all its forms, not only the data centric semweb.

 

Now, I know what a protocol is, and I know what a secret protocol is. I even know how to hide one in plain sight so there is “trust” (if one believes trust is the presence of hidden kill switches, operated by govts when needed), or “trust” (if one believes turst is the absence of that which include any deception, specially parsed words, subverted assumptions etc). So protocols are fun, because swap a protocol and trust means 2 complementary things (and that’s the point…)

 

I think I know what a webid is (a URI that dereferences to an verifiable identity document).

 

Now, its in that very definition that I tried to reference the notion of protocol.  It’s all in the inserted adjective: “verifiable”. If I used better American writing style, Id probably have to go with something more explicit: a URI that dereferences to an identity document using a verification protocol).

 

 

This is the theory Im after. If this sense of protocol in ”webid protocol” is not as intended, then what is it?

 

With the admnission that we have LEFT the confines (but not the discipline of RDF), I think folks are DENYING that such as the following is essential to concept of “the” webid protocol:

http://www4.wiwiss.fu-berlin.de/bizer/pub/Carroll_etall-WWW2005.pdf

 

Looking at the incubation proposal, I believe (from Stephan’s terminology) that folks are asserting that such a trustworthiness provider COULD BE one method of verification, but that’s as far as the “protocol” relationship goes. Rather than say: Carrol et al fits in the trust box of the semantic web model, we now say: Carrol et al is a webid protocol instance; one of many.

 

Now I like that (if its intended), as Its something the Kantara folks could latch onto, here and today. It’s a webby form of what they are already playing with from other constituencies (the US government work on trying to add trust provider and trust frameworks to openid)

 

From: Kingsley Idehen [mailto:kidehen at openlinksw.com] 
Sent: Thursday, December 16, 2010 10:34 AM
To: peter williams
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] WebID Incubator Charter draft

 

On 12/16/10 11:26 AM, peter williams wrote: 

You previous educated me (for one) well on the “intuitions” of linked data, much as Henry educated me well on the core constructs of RDF, FOAF, and semantic modeling in general, and Dan taught me lots about the wider “point of” RDF, the enabler.

 

Can you point to something that talks about semantics of protocols?


This might help: http://www.slideshare.net/kidehen/iss-1

My key point is that WebID doesn't need any RDF syntax incursions. None whatsoever.

Kingsley





 

Im very used to (formal) semantics of authentication protocols (e.g. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.9593) . But, Ill guess you have a more webby concept than all that rather old-fashioned stuff.

 

From: foaf-protocols-bounces at lists.foaf-project.org [mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Kingsley Idehen
Sent: Thursday, December 16, 2010 7:52 AM
To: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] WebID Incubator Charter draft

 

On 12/16/10 9:31 AM, Jiří Procházka wrote: 

On 12/16/2010 02:45 PM, Kingsley Idehen wrote:

On 12/15/10 5:03 PM, peter williams wrote:

I like this proposal.
 
What I don't want is the scope to be limited to the linked data movement (or
its various axioms about the world should be).

 
I think you should broaden that and maybe say: it shouldn't be confined 
to RDF (overtly or covertly).

WebIDs need to be big, like DNs and domain names are big.

Yes, Internet of Things scope.
 
Kingsley

 
Suppose you want to resume the offshoot of "PEM certificate- was
cert:public_key" discussion, where Henry proposed a way of making WebID
independent on RDF.
I have previously though this is a good idea, but then I realized a
functional mistake and considering all options, I think using RDF with
one required serialization is best. The discussion and my previous
opinion can be traced from the following message:
http://lists.foaf-project.org/pipermail/foaf-protocols/2010-October/003936.html


You describe an implementer decision re. RDF. We can't make such assertions re. Semantics of the Protocol.

We must keep Syntax and Semantics distinct. Must also keep Spec and Implementations distinct etc..

Our own WebID implementations are RDF based, we use RDF/XML extensively for some very sophisticated things, but none of this justifies forcing it into WebID spec (overtly or covertly).

I push-back on RDF for good reasons, in due course, may actions will become much clearer re. efforts such as Linked Data and WebID.

Kingsley




 
Best,
Jiri
 
 
 
_______________________________________________
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols







-- 
 
Regards,
 
Kingsley Idehen       
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/%7Ekidehen> 
Twitter/Identi.ca: kidehen 
 
 
 
 






-- 
 
Regards,
 
Kingsley Idehen       
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101216/818ba004/attachment-0001.htm 


More information about the foaf-protocols mailing list