Re: New WebID spec on identity.

On 11/19/12 4:23 PM, Andrei SAMBRA wrote:
>
> On Mon, Nov 19, 2012 at 4:06 PM, Stéphane Corlosquet 
> <scorlosquet@gmail.com <mailto:scorlosquet@gmail.com>> wrote:
>
>
>     On Mon, Nov 19, 2012 at 3:55 PM, Melvin Carvalho
>     <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>
>
>
>         On 19 November 2012 21:36, Ted Thibodeau Jr
>         <tthibodeau@openlinksw.com <mailto:tthibodeau@openlinksw.com>>
>         wrote:
>
>             * On Nov 19, 2012, at 12:01 PM, Henry Story wrote:
>             >
>             > For this you need to put up an issue in the issue tracker
>             >
>             > http://www.w3.org/2005/Incubator/webid/track/
>             >
>             > in the product WebID-definition. Point to this e-mail
>             for details.
>
>             ISSUE-69 exists for this purpose.
>
>             http://www.w3.org/2005/Incubator/webid/track/issues/69
>
>             The name/description was short-handed to get it into place
>             before
>             being forgotten.  To my eyes, your (Henry's) "additional
>             notes" in
>             that issue reflect less of what actually happened in the
>             telecon,
>             and more of what your interpretation of the conversation was.
>
>             There are strong arguments for both hashed and hashless URIs.
>             I see this these arguments as reason to permit both, and to
>             include some discussion of the strengths and weaknesses of
>             each
>             in the documents we produce -- including both the costs of
>             lookup
>             on 3xx redirection (both client- and server-side) and the
>             increased
>             flexibility that may be provided by such explicit
>             indirection, vs
>             the lower cost of lookup without 3xx redirection and the
>             limited
>             flexibility mandated by this implicit indirection.
>
>
>         I've been wondering for some time now what you gain from the
>         303 dance.
>
>         Sorry if I've missed something, but could you go over the
>         benefits of having, say
>
>         http://graph.facebook.com/dave
>
>         over
>
>         http://graph.facebook.com/dave#
>
>
>
>     Have you checked the Facebook paper from Jesse Weaver and Paul
>     Tarjan at
>     http://semantic-web-journal.net/sites/default/files/swj282_0.pdf ?
>
>
> Nice find, Steph! Here is a relevant snip from the paper:
>
> ....
> "As mentioned, information about an instance with primitive identifier 
> id can be found at /id. Thus, the simplest solution for minting a 
> Linked Data URI for the instance is to append a fragment to the URI. 
> The common conventions of using fragments #this and #me were 
> considered, but in the end, the empty fragment # was chosen so as to 
> require the least amount of modification to the URI possible."
> ....
>
>
>     But more importantly, the question here is not about deciding
>     which one is best, but whether we should pick one or instead leave
>     it open so that people can implement whichever approach they
>     prefer, and simply rely on the nature of HTTP.
>
>     Steph.
>
>
Put that snippet into context. The paper is talking about Facebook's 
decisions. When I speak about Facebook I speak about the malleability of 
their structured data as a result of adopting Linked Data principles. 
Put differently, this is about being able to work with Facebook hosted 
data without waiting for Facebook. They've don't their bit by publishing 
Linked Data. Thus, nobody needs to wait for them re. Linked Data based 
initiatives such as WebID over TLS.

Remember, WebID and its authentication protocol are about a distributed 
and federated social web where everyone has the ability to be the 
passport office and passport holder, not a silo web :-)

For some history, when RDBMS engines ruled the roost, we went through 
the same drive for openness via standards such as ODBC and JDBC. Now 
that we have HTTP we can extend those models such that we move from Open 
Database Connectivity to Open Data Connectivity.

Links:

1. https://plus.google.com/u/0/s/idehen%20data%20connectivity%20odbc -- 
some post on G+ about the evolution from Open Database Connectivity to 
Open Data Connectivity via Linked Data

2. http://bit.ly/Sao1js -- when I used to refer to Linked Data as WODBC 
(Web Open Database Connectivity) .

-- 

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