さて、グラフというのはノードとエッジで構成されていますが、エッジはノードがないと定義できません。

　ということはつまり、まず定義するべきはノードということになります。このノードの定義は、一意かつ不変である必要があります。つまり、あるネット上のヒト、モノ、情報はつねに同じ形で表現できる必要があります。

　ネットには幸いURL（URI）というものがあります。

　URLはネット上での場所を定義するものですから、ノードとして使うには現時点ではおそらく最適です。たとえば最近ネットでの認証としてよく使われ始めているOpenIDも、フォーマットとしてはURLを使っています。

　これはヒトをノードとして定義している手法の一つだと言えます。一つ問題があるとすれば、ヒトと情報を同じURLで表現してしまうことがある、というものがあります。モノや情報はすでにURLで表現されることが一般的になってきています。

　ブログのパーマリンクやAmazonの商品URLなどがその例です。情報（コンテンツ）の場合には、ほぼ一意なURLというものが存在しますが、商品、いわゆるモノについては、一つについて複数のURLが存在することはままありますが、一つのURLが複数のモノを表現するよりはましであると言えます。

　URLによって、ヒト、モノ、情報をノードとして定義することができれば、エッジは二つのノードを結ぶ線ですから、ノード二つと必要あれば方向性という情報によって定義することができます。

　ちなみに方向性があるものを有向グラフ、ないものを無向グラフといいます。エッジを表現する手段として現時点で最適なのは、おそらくXMLでしょう。AtomやRDFはそのままグラフを表現する手段として使うことができます。

　ソーシャルグラフを考えるときは、こうしたノードやエッジの情報を相互にやり取りできる必要があります。

　ネットの本質は今も昔もInteroperabilityです。Googleの提唱するOpenSocialや、DataPortability.orgなどはこういった部分への寄与であると言えます。

　OpenSocial自体は、ノードやエッジといったデータのInteroperabilityを目的としたものではなく、アプリケーションのportabilityを目的としたものですが、アプリケーションにportabilityをもたせるためにはデータのInteroperabilityは必須であり、結果としてデータのInteroperabilityを実現するための手段ともなりえます。

　Dataportability.orgはそもそもデータ自体のportabilityを目的としています。OpenSocialにしてもDataPortability.orgにしても、また第三の手法を用いるとしても、いずれにしても必要なことは以下の3つです。

• 1. ノードを表現する手法がある
• 2. エッジを表現する手法がある
• 3. 情報を交換する手法がある

　1はID、2はデータフォーマット、3はプロトコルです。

　IDとデータフォーマットとプロトコルによって、ネットはInteroperabilityを確保しています。これはメールでもwwwでもftpでもメッセンジャーでも同じです。

　ソーシャルグラフという新しい概念/サービス/アプリケーションを実現する場合にも、この3つを定義して共有することができれば、Interoperabilityを実現することができるようになります。