例えば、今現在存在する、ヒト（ユーザー）の関係を表現する手法として、XFN（XHTML Friends Network）というmicroformatsの一種や、FOAF（Friend Of A Friend）というRDFフォーマットの一種がありますが、これらはいずれもXMLを用いています。

　具体的なフォーマットとしてはどういうものがいいかはさておき、いずれにしてもXMLを使用するのが現状では妥当でしょう。ノードが表現できていれば、エッジを表現するのはそれほど難しくありません。

　エッジには実に様々なものがあります。例えばSNSのリンクや、ECサイトでの購買、ブログの購読などこれらは全てエッジです。

　また、エッジには種別と強弱もあります。例えばSNSに良くある足跡機能もエッジであると言えますし、リンクも現在のSNSは友人（フレンド）しかないですが、おそらくそのうち、知人、親友、家族、会社などさまざまな種類のリンクが登場するでしょう。

　強弱で言えば、リンクは足跡よりも強いエッジですし、ECサイトで商品ページを見るのは購買よりも弱いエッジと見ることもできます。

　そしてこれらのエッジはサイトを跨いで共通の基準を持っている必要があります。例えばSNSにおけるリンク、足跡、ソーシャルブックマークにおけるブログの購読の場合、

• リンク > ブログの購読 > 足跡

　という強弱関係が妥当かもしれません。

　また、Twitterのようなミニブログ（マイクロブログ）の一方向リンクは、SNSのリンクよりは弱いがブログの購読よりは強そうです。こういったエッジの強弱、種別の定義を妥当に行えるかどうかは、とても重要であると言えます。

データ交換はHTTP

　ノードとエッジが表現できた場合、次に決めなければいけないのがプロトコルです。データは相互に交換、運用できてこそ意味があります。ネットの本質はいつでもInteroperability（相互運用性）です。

　プロトコルは現状ですとHTTPが最有力であると言えます。実際、XML（XHTMLやRDFなど）のやり取りは現在ほとんどHTTP上で行われていると言っても過言ではありません。

　ただ、HTTPには一つ欠点があります。それはクライアントサーバ型のプロトコルであるということです。

　CometのようなHTTPをベースにしたプッシュ型の手法もありますが、Cometはクライアントから起こしたセッションを保持しておき、サーバ側からの送信が必要になった時点でレスポンスを返し、すぐまたクライアントからセッションを起こすという手法なので、ほとんどの実時間においてセッションが張られているということになります。

　通常のTCP/IPとHTTP実装をそのままComet的な手法で使うと、コネクション数がボトルネックになってしまいます。

　このあたりをCometのような疑似プッシュ型に最適化した実装も登場してきていますが、まだまだ未知数であると言えます。本来HTTPはクライアントサーバ型プロトコルとして設計されているので、無理がある感は否めないところです。

　ソーシャルグラフで使用する情報をサーバだけがやり取りしている間はサーバ間通信でも問題ないとは言えますが、いずれクライアントが直接ソーシャルグラフの情報（特にエッジ情報）をダイナミックに送るような場面は増えていくとすると、P2P型のプロトコルを使用したほうが良いかもしれません。

　ただ現状、十分普及してかつ「枯れている」P2Pの実装がありませんので、現実解はHTTP（とCometのような疑似プッシュ手法）となっています。もっとも、現在のところはプッシュで情報を送る必要があるケースが少ない、というのも事実です。

　さて、ここまでのところをまとめますと、ノードの表現はURL、エッジの表現はXML、データ交換は（現状では）HTTPが最適解であると思います。これでソーシャルグラフに必要な情報をやり取りできるようになりました。

ソーシャルグラフの活用法

　その次に必要なことは、やり取りする情報をどう活用するかです。