On 2003-10-13 08:30:00, Allan Engelhardt wrote in CYBAEA Journal:
It seems to me that the requirements for systems like LinkedIn (which we covered obliquely in a previous note), Friendster, and many others, all of which allow you to document your social networks and, ultimately, profit from them, can be understood by considering normal, "real-world" social interactions and their limitations.
We will compare the various online services in a future note (please contact us with your favorite services) but briefly the requirements seem to us to include at least the following points (which are compared with features found at LinkedIn.
1. Ability to create links between members.
This is similar tot he real-world experience of exchanging business cards and is the basis for creating the electronic representation of your social networks.
This is implemented by LinkedIn through the invitations
feature.
2. Ability to delete links.
My address book is ever growing: I don't think I have ever deleted
anybody and I have over 1,000 contacts. However, I do not have 1,000
useful social links, for any meaningful definition of useful
.
Many of these are old contacts where I have not kept the relationship
up; others are people with whom I have fallen out; and looking
through my address book I have to study the notes section pretty
carefully to even remember who most of these people are.
They are not people through whom I could usefully introduce you to somebody you want to meet. Since this is pretty much the purpose of facilities like LinkedIn, they should not be represented as active links.
The ability to delete links seems like a basic feature, and yet it is
missing from LinkedIn. Allen Blue of LinkedIn points out that it is
available through a simple customer service function
and that
to date they have had just one request to break a connection
.
You may want to consider further refinements. Perhaps links should expire over time if they are not used? (For that you'd need some integration into your email and diary programs--more on that later.)
3. Connections only through established links
I should obviously not be able to spam the entire user database. The system is not a telephone directory. The point of the system is the network and specifically the links between people. To contact you I should go through somebody we both know, perhaps a chain of people but people who are already connected. LinkedIn implements this feature, though it allows individual users to disable it by allowing contacts from any members.
This is similar to how we operate real social networks: they work by introductions and this is one aspect of this.
4. Ability to publish your details in order to solicit contacts.
Similar to taking out a stand at a conference exhibition and
distributing your business cards, there needs to be some way for
other people to realize that they want to contact you. Linked in
implements this through Profiles
.
5. Ability to introduce people you know.
Allan, meet Andy; Andy, meet Allan.
One of the most common
exchanges in the business world (and, indeed, in the social world),
the basic introduction should be a feature of any system for managing
links.
Curiously, it is currently missing from LinkedIn, though Allen Blue
assumes me it will appear soon
.
6. Improvement on Real-World Networks (1): Show paths between any two members.
The search problem in a Small-World network is something we have touched upon previously. It basically boils down to this: everybody may be connected to everybody else through only a few steps, but can I find those steps--can I search the network from within the network?
One obvious way is for the system to be able to show the paths
between any two members. I may know (through Profiles
as in
point 4 above) that I want to contact you, but how do I find out who
can introduce me? Asking all my friends to ask all their friends
… to see if anybody knows you is very wasteful and risks
overloading the network--much like computer viruses work.
It should be easy for the system to show the paths between me and you, and indeed this is a core feature of LinkedIn.
7. Improvement (2): Limited broadcast of request
The problem is this: if I know all the questions that I may be asked,
then I can obviously structure my Profile
(cf. point 4 above)
to answer them. But it does not take much reflection to realize that
this will never be the case. There are always unusual requests;
indeed they are often the most interesting and valuable.
There need to be a mechanism to ask for help. The mechanism has to work but without overloading the network (as discussed above).
There are probably several ways of implementing this. My suggestion is for a bulletin board that is only visible by people who are no more than three links from me. That way, they can connect me to another member (LinkedIn has a limit of four degrees of separation for connections) if they know one who can satisfy my request. Or they can even invite a non-member to join, and then connect the two of us.
This is not currently available at LinkedIn.
8. Goal: Automatically update my network based on e-mails, meeting, telephone calls, etc.
In the real-world, when I meet somebody or talk to them on the phone, they automatically become part of my network. When I don't speak to them for years, they cease to be part of my network.
Somebody compared LinkedIn to a CRM system, but even the most basic such system has maintenance facilities for contacts and relationships.
As it stands, when I meet somebody new I have to update
That seems to be the real killer. How do people get the time to maintain the multiple representations of their networks? How do you expire old links? Out-of-date information is often worse than no information.
But this is a hard problem to solve. Stay tuned and add your comments using the links below.
On 2009-07-02 20:33:00, Allan Engelhardt wrote in CYBAEA Data and Analysis:
I am a sucker for good quality data. I wrote about data.gov, the US Government data site before, and now I find OECD Statistics which has some 300 data sets, many of which seems to be readily accessible (though some may require subscription)
Read more (~53 words).
On 2009-06-16 10:27:00, Allan Engelhardt wrote in CYBAEA Data and Analysis:
I like the "multicore" library for a particular task. I can easily write a combination of if(require("multicore",...)) that means that my function will automatically use the parallel mclapply() instead of lapply() where it is available. Which is grand 99% of the time, except when my function is called from mclapply() (or one of the lower level functions) in which case much CPU trashing and grinding of teeth will result.
So, I needed a function to determine if my function was called from any function in the "multicore" library. Here it is.
Read more (~190 words).
On 2009-06-12 10:23:00, Allan Engelhardt wrote in CYBAEA Data and Analysis:
Somebody on the R-help mailing list asked how to get Rmpi working on his Fedora Linux machine so he could do high-performance computing on a cluster of machines (or a single multicore machine) using the R statistical computing and analysis platform. Since it is unusually painful to get working, I might as well copy the instructions here.
Read more (~414 words, 2 comments).
On 2009-06-09 11:23:00, Allan Engelhardt wrote in CYBAEA Data and Analysis:
O’Reilly has published Data Mashups in R as a $4.99 PDF download in their Short Cut series. In 27 pages it takes you through an example of how to combine foreclosure information with maps and geographical information to produce plots like the one here. This is all done with the R statistical computing and analysis platform.
Read more (~108 words).
On 2009-06-01 07:07:00, Allan Engelhardt wrote in CYBAEA Data and Analysis:
Hugh Miller, the team leader of the winner of the KDD Cup 2009 Slow Challenge (which we wrote about recently) kindly provides more information about how to win this public challenge using the R statistical computing and analysis platform on a laptop (!).
Read more (~456 words).
Join the discussion
There are no comments yet. Be the first to comment.