Re: [webid spec] overview section

On 11/20/12 4:43 PM, Nathan wrote:
> Kingsley Idehen wrote:
>> On 11/20/12 3:52 PM, Nathan wrote:
>>> Kingsley Idehen wrote:
>>>> On 11/20/12 2:50 PM, Andrei SAMBRA wrote:
>>>>>
>>>>>
>>>>>       I think it may be useful also to explain how these WebIDs can
>>>>>     then be used to
>>>>>     create social networks - across servers. ( I can send a 
>>>>> graphic of
>>>>>     interlinked WebIDs for
>>>>>     that ).
>>>>>
>>>>>
>>>>> Isn't this out of scope for the spec? It's up to each of us to 
>>>>> decide how we want to use WebIDs.
>>>>
>>>> It's okay for a conceptual guide. Such a guide should have a least 
>>>> one usecase scenario. The moment to get a profile graph from the 
>>>> de-reference of a WebID you are in social web/network territory.
>>>
>>> WebID 1.0 is getting to the point where there's almost nothing to 
>>> specify, it's a one liner of words which equate to "a dereferencable 
>>> URI for an Agent", 
>>
>> I wish :-)
>>
>> We haven't been able to get beyond:
>>
>> 1. dereferencable URI that denotes an Agent
>> 2. dereferencable HTTP URI that denotes an Agent
>> 3. derferencable hash based HTTP URI that denotes an Agent.
>>
>> Even the indentation above highlights interop issues with visual 
>> broader and narrower effect.
>
> Yup, it's just extra stars really, (1) is required (2) is 
> common-linked-data (3) is "nicest".
>
> Interop depends on perspective and context, if working within the 
> realm of HTTP and RDF, then punting the most common/simple pattern 
> will have benefits, if working within a more general web realm, or 
> even net realm, then increased generality will lead to more interop.
>
> Which is where's it's interesting, because obviously the more general 
> WebID is defined, the more potentially-interoperable it is, however 
> the tighter it's defined, the more realistically-interoperable it is, 
> as it limits adoption pain and makes it simpler to implement and 
> support within the common HTTP realm.
>
> Both are important, and there's a trade-off to be made.

Yes, but an Architect goes for interop. An Engineer optimization. Thus, 
specs should be driven by Architecture that's as dexterous as is 
possible while Engineering implements the specs as optimal as is 
possible :-)

The cost of HTTP URIs vs hash HTTP URIs is utterly insignificant 
relative to the interop and adoption (not implementation) costs. Many 
simple implementations doesn't in anyway imply mass adoption. A single 
"deceptively simple" solution can trigger and explosion. Exhibit #1 is 
the World Wide Web re. fusion of TCP/IP and Hyperlinks via URI (dare I 
say) abstraction.


>
>>> everything else I see is just padding, so may as well be padding 
>>> which shows how WebIDs can be used, imho - if we're gunning for 
>>> adoption here that is.
>>
>> Yes.
>>
>>>
>>> Something I haven't noticed (may have missed), is any text which 
>>> shows a distinction between an Agent Identifier, and an Identifier 
>>> for a UserAccount, like twitter or g+.
>> Yep.
>>
>> One for the principals bucket, methinks. And yet another reference to 
>> "principal" from WebDAV ACL [1]
>
> Not a term I've heard used for quite a while, but it certainly fits 
> the bill, "principal" is almost synonymous with the way we use the 
> term "agent".
>
> Best,
>
> Nathan
>
>


-- 

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