Re: Network identity / brand

On 7/9/12 1:51 AM, Michiel de Jong wrote:
> On Sun, Jul 8, 2012 at 10:26 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> Yes, URI everything and everything is Cool!
> sure, but would you propose it as a brand? Reading back, we've
> mentioned the following "brands" for the identity of fedsocweb as a
> network, both as candidates for the phrase "Are you on X?" and for the
> phrase "What is your X?":
>
> fedsocweb
> FedSocNet
> Web
> FSW
> FedSocWeb ID
> Node
> WebID
> NetID
> user address
> URI (not sure if this was a serious proposal or just a remark)

WebID, NetID are great aptonyms. Thus, solid for marketing oriented 
branding.
>
> and for the identifier string format we have discussed:
> user@host
> http(s)://host/path/to/user
> either user@host or http(s)://host/path/to/user
> =markus, =>markus, !markus, @<nickname>
> =markus.com, <markus.com>, %markus.com, *markus.com, markus*com
>
> and i would like to add an option (for discussion's sake): firstName
> lastName [city [other details]], that's to say, plain text search.

What we are really trying to do here is leverage URIs, data access 
protocols, and structured data as a mechanism for delivering verifiable 
identity (at InterWeb-scale)  using agent oriented identifiers, that 
resolve to profile graphs. Thus, solutions in realm will benefit from 
incorporating emerging end-user realm patterns such as: @<nym> or +<nym> 
. At the current time, @<nym> is clearly the dominant pattern.

>   We
> will need to federate search anyway, so why not just do it now? nodes
> can create an index of their own users, for each one listing
> firstName, lastName, city, language (skype uses this as a search
> criterium and i think it's brilliant), avatar, and globally user
> identifier string.

Search simply feeds off this federated profile substrate. This is 
basically another area where Linked Data simply exposes another Web 
interaction and exploitation dimensions. We only go off the rails when 
we assume this is all RDF specific when it simply isn't. Just let 
de-referencable URIs do their thing.

> This can be an atom/rss feed, in which case we can
> add a command that means 'user deleted', and maybe we want to
> differentiate explicitly between new users and profile updates.
> Putting this data together for multiple nodes, if each node has the
> data of each other node, you can rehash it to be a prefix -> record
> search for each field, and you have essentially created 5 distributed
> hash tables (DHT), one per search term.

Now you are talking about replication and synchronization. There are 
many existing protocols that make this happen once their is a commitment 
to URIs and structured data. Users need the ability to push or pull 
data, not one or the other.
>
> Nodes would have to pro-actively follow each other in order to be part
> of the same DHT. But of course we could set up a public hub that makes
> this easier, just like superfeedr runs a public PuSH node.

When you say "a public hub" you break the model you seek. Each personal 
data space is many things, in some cases it might be the hub of a 
specific trust net in others its just part of the broad federation of 
trust nets etc..

> And if we
> do it as linked data, then everybody can index it, and these search
> results can naturally become part of what Google calls its Knowledge
> Graph. Just like the rest of the web.

Exactly!

>
> I think federating user search is what will make our network "feel"
> like a network.

Yes, basically, its more than "search" think of this as "precision find" 
i.e., you find the data you need via traversal across a mesh of Linked 
Data exposed at the user level as personal data spaces.
>
>
>


-- 

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