Re: telconf 07-11-2012 : what is webid

Kingsley Idehen wrote:
> On 11/16/12 4:59 AM, Henry Story wrote:
>> On 16 Nov 2012, at 00:08, Jürgen Jakobitsch 
>> <j.jakobitsch@semantic-web.at> wrote:
>>
>>>> I'm designing systems, with interoperability and adoption in mind. In
>>>> the case of WebID, we believe that it means "building on top of LDP",
>>>> which I recall is the only W3C Working Group that is chartered to work
>>>> on defining the platform (Read-Write) for RDF data *on the Web*. This
>>>> Community Group has *no chance* to bring WebID to LDP if it's not
>>>> built on top of LDP, you need to realize that.
>>> hi alexandre,
>>>
>>>
>>> 1. webID is not an annex to ldp, it's neither on top of ldp or else
>>> related, why should it be. should we redefine dope, sioc, foaf just to
>>> please ldp?
>>> (let that sound to your ears : a doap:Project is a #URI that denotes a
>>> software project)
>>> 2. webID has nothing to do with deployment and data-io, hence it has
>>> nothing to do with ldp.
>>> 3. not every triple on this planet will be hosted on an ldp system
>>> sometimes soon
>>> 4. on the other i could always host a webID on an ldp system, that's it
>>> 5. webID does NOT rely on ldp. when i choose to host my webID on an ldp
>>> system there WILL be a turtle representation (if the ldp spec says so)
>>> and i CAN have a #URI, that's it.
>> Well argued that they are not the same.
>> On the other hand we should consider some very important things that 
>> it will
>> bring:
>>
>>    1. Automatic provisioning of WebIDs to robots and other agents.
>>
>>      A software robot could create an account by POSTing a request for 
>> a new collection
>>    provision the WebID profile document quickly, and get going. So 
>> this could make it easy
>>    to help a lot of apps get WebIDs
>>
>>    2. Pingback and friending
>>
>>      one can add friending requests using Pingback to an LDP server in 
>> a more generic way
>> than what we had now, thereby creating and growing the social networks 
>> strength.
>>
>>    3. A community that needs WebID
>>
>>     LDP can't really work without WebID over TLS in my view - not 
>> efficiently at least. It
>> needs ways to do distributed access control - if only because large 
>> companies want to
>> deploy it. They will want to use it on the open internet, and if they 
>> do then they need
>> a way to do distributed authentication - because they will inevitably 
>> have information they
>> want to protect: e.g.: they can't allow everyone in the world to write 
>> RDF to their system.
>>
>>   But they can only get very negative pushback if WebID over TLS is 
>> tied directly into their
>> framework. So we that is why we have to decouple WebID and public 
>> keys. And we develop
>> the Identity Interoperability spec/wiki page to help show how everyone 
>> can participate.
>>
>>    In fact a lot of people here already are working on LDP
>>      - Openlink is working in this area.
>>      - Andrei is working on enabling my-profile for LDP
>>      - I am implementing it in Scala
>>      - Joe Presbrey's data.fm has WebID and something close to LDP
>>      - .... ( anyone else? who is doing WebID Auth over TLS and LDP?)
>>
>> So alignment is important - not very difficult to do for us anyway.
> 
> Yes, but WebID and LDP are orthogonal endeavors. We should keep it so 
> i.e., don't make decisions about WebID that a specifically aimed at LDP. 
> All of these efforts are based on AWWW which is inherently loosely coupled.
> 
> WebID adoption won't be going through LDP, it will happen on the back of 
> its own merits in relation to a specific problem space i.e., Web-scale 
> verifiable identity.

+1, they are orthogonal, it's just tempting for the people in this 
community to want to merge them together, since we're all working and 
interested in all three (LDP, WebID, ACL) - they compliment, but only 
when loosely coupled as Kingsley points out.

Keeping the three separate, will ensure separation of concerns and tweak 
out any cross cutting concerns, so on the merits of that alone, I'd be 
in favour of us all keeping them distinct whenever possible.

Ty for trying to keep everybody on track Kingsley, appreciated.

Best, Nathan

Received on Friday, 16 November 2012 13:10:34 UTC