The Social Graph API was launched February 1st right before the Social Graph Foo Camp. The main Foo Camp starts today, so this seems like a good time to launch some more SGAPI features.
So far the Social Graph API has only had 1 method (/lookup) and 1 other debug method (/testparse). Now there's the first new high-level API, "otherme".
No docs are written yet, so consider this a sneak preview if you'd like:
q - comma-separated list of URLs/emails that a user has said are theirs jscb - JSON-P callback, optional. pretty - optional boolean: pretty-print sgn - optional boolean: include sgn canonicalizationd details/nodes (including sgn mboxsha1sum nodes)
Response is all the other URLs that user has, not including the one or more you passed in in the 'q' parameter. They're keyed by URL and include all the new attributes that are being parsed (name, photo, rss, atom, etc).
Note that this is simply a mechnical transformation on the /lookup method, not offering anything that wasn't possible before. It's just that the transformation was tedious and error-prone and silly to have to repeat in each client library. Hopefully putting it in the server makes it more convenient for everybody.
Why is this useful? A lot of websites are now letting you list your other websites/profiles on your profile, but it's just as annoying to repeat this information on every site as it is to redefine your friends everywhere. If the site incrementally hits this API in the background as you enter profile URLs, the site can then recommend you link/share your other websites. Examples of sites that let you enter your other profile URLs and could use this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, Friendfeed, Mugshot. And that's just off the top of my head from sites I'm familiar with. I'm sure there's a bunch more.
(Also new: Google Profiles[1] data is now served live, rather than from crawl data. It'd be nice to do this optionally also for other willing sites in the future so I did Google Profiles as an experiment and to setup the infrastructure for it.)
Docs to come soon. Let me know if there's any questions/requests in the meantime.
> The Social Graph API was launched February 1st right before the Social Graph > Foo Camp. The main Foo Camp starts today, so this seems like a good time to > launch some more SGAPI features.
> So far the Social Graph API has only had 1 method (/lookup) and 1 other > debug method (/testparse). Now there's the first new high-level API, > "otherme".
> No docs are written yet, so consider this a sneak preview if you'd like:
> q - comma-separated list of URLs/emails that a user has said are theirs > jscb - JSON-P callback, optional. > pretty - optional boolean: pretty-print > sgn - optional boolean: include sgn canonicalizationd details/nodes > (including sgn mboxsha1sum nodes)
> Response is all the other URLs that user has, not including the one or more > you passed in in the 'q' parameter. They're keyed by URL and include all > the new attributes that are being parsed (name, photo, rss, atom, etc).
> Note that this is simply a mechnical transformation on the /lookup method, > not offering anything that wasn't possible before. It's just that the > transformation was tedious and error-prone and silly to have to repeat in > each client library. Hopefully putting it in the server makes it more > convenient for everybody.
> Why is this useful? A lot of websites are now letting you list your other > websites/profiles on your profile, but it's just as annoying to repeat this > information on every site as it is to redefine your friends everywhere. If > the site incrementally hits this API in the background as you enter profile > URLs, the site can then recommend you link/share your other websites. > Examples of sites that let you enter your other profile URLs and could use > this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, > Friendfeed, Mugshot. And that's just off the top of my head from sites I'm > familiar with. I'm sure there's a bunch more.
> (Also new: Google Profiles[1] data is now served live, rather than from > crawl data. It'd be nice to do this optionally also for other willing sites > in the future so I did Google Profiles as an experiment and to setup the > infrastructure for it.)
> Docs to come soon. Let me know if there's any questions/requests in the > meantime.
It doesn't return a strongly-connected set, no. It's the union of the follow-me (fme=1) sets as returned by lookup, with duplicates removed (including cases where sgn pk and ident nodes are both returned).
> 2008/7/12 Brad Fitzpatrick <bradf...@google.com>: > > The Social Graph API was launched February 1st right before the Social > Graph > > Foo Camp. The main Foo Camp starts today, so this seems like a good time > to > > launch some more SGAPI features.
> > So far the Social Graph API has only had 1 method (/lookup) and 1 other > > debug method (/testparse). Now there's the first new high-level API, > > "otherme".
> > No docs are written yet, so consider this a sneak preview if you'd like:
> > q - comma-separated list of URLs/emails that a user has said are theirs > > jscb - JSON-P callback, optional. > > pretty - optional boolean: pretty-print > > sgn - optional boolean: include sgn canonicalizationd details/nodes > > (including sgn mboxsha1sum nodes)
> > Response is all the other URLs that user has, not including the one or > more > > you passed in in the 'q' parameter. They're keyed by URL and include all > > the new attributes that are being parsed (name, photo, rss, atom, etc).
> > Note that this is simply a mechnical transformation on the /lookup > method, > > not offering anything that wasn't possible before. It's just that the > > transformation was tedious and error-prone and silly to have to repeat in > > each client library. Hopefully putting it in the server makes it more > > convenient for everybody.
> > Why is this useful? A lot of websites are now letting you list your > other > > websites/profiles on your profile, but it's just as annoying to repeat > this > > information on every site as it is to redefine your friends everywhere. > If > > the site incrementally hits this API in the background as you enter > profile > > URLs, the site can then recommend you link/share your other websites. > > Examples of sites that let you enter your other profile URLs and could > use > > this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, > > Friendfeed, Mugshot. And that's just off the top of my head from sites > I'm > > familiar with. I'm sure there's a bunch more.
> > (Also new: Google Profiles[1] data is now served live, rather than from > > crawl data. It'd be nice to do this optionally also for other willing > sites > > in the future so I did Google Profiles as an experiment and to setup the > > infrastructure for it.)
> > Docs to come soon. Let me know if there's any questions/requests in the > > meantime.
On Sun, Jul 13, 2008 at 9:25 AM, Ade Oshineye <a...@google.com> wrote:
> Are these links meant to be bi-directional? > The following 2 urls give different results implying that the SGApi > can only follow links between accounts and doesn't infer > relationships:
... though I'm curious what you mean by "doesn't infer relationships".
So if you start there, it's a dead-end. What would you expect it to do? (I do plan to add a fuzzy=1 option in the future, where if a node is uncontested we could walk up the me edge in the wrong direction. Fuzzy mode would only be for when human reviewers are involved.)
> 2008/7/12 Brad Fitzpatrick <bradf...@google.com>: > > The Social Graph API was launched February 1st right before the Social > Graph > > Foo Camp. The main Foo Camp starts today, so this seems like a good time > to > > launch some more SGAPI features.
> > So far the Social Graph API has only had 1 method (/lookup) and 1 other > > debug method (/testparse). Now there's the first new high-level API, > > "otherme".
> > No docs are written yet, so consider this a sneak preview if you'd like:
> > q - comma-separated list of URLs/emails that a user has said are theirs > > jscb - JSON-P callback, optional. > > pretty - optional boolean: pretty-print > > sgn - optional boolean: include sgn canonicalizationd details/nodes > > (including sgn mboxsha1sum nodes)
> > Response is all the other URLs that user has, not including the one or > more > > you passed in in the 'q' parameter. They're keyed by URL and include all > > the new attributes that are being parsed (name, photo, rss, atom, etc).
> > Note that this is simply a mechnical transformation on the /lookup > method, > > not offering anything that wasn't possible before. It's just that the > > transformation was tedious and error-prone and silly to have to repeat in > > each client library. Hopefully putting it in the server makes it more > > convenient for everybody.
> > Why is this useful? A lot of websites are now letting you list your > other > > websites/profiles on your profile, but it's just as annoying to repeat > this > > information on every site as it is to redefine your friends everywhere. > If > > the site incrementally hits this API in the background as you enter > profile > > URLs, the site can then recommend you link/share your other websites. > > Examples of sites that let you enter your other profile URLs and could > use > > this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, > > Friendfeed, Mugshot. And that's just off the top of my head from sites > I'm > > familiar with. I'm sure there's a bunch more.
> > (Also new: Google Profiles[1] data is now served live, rather than from > > crawl data. It'd be nice to do this optionally also for other willing > sites > > in the future so I did Google Profiles as an experiment and to setup the > > infrastructure for it.)
> > Docs to come soon. Let me know if there's any questions/requests in the > > meantime.
At the moment any tool based on the idea that the user enters some of their urls and the system works out their urls will still have to implement something like the following algorithm:
while len(urlsToVisitSet) > 0: for url in urlsToVisitSet.copy(): #network call to sgapi fetchedUrlsSet = fetchOtherUrls(url) visitedUrlsSet.add(url) for fetchedUrl in fetchedUrlsSet: if fetchedUrl not in visitedUrlsSet: urlsToVisitSet.add(fetchedUrl) userUrlsSet = userUrlsSet.union(fetchedUrlsSet)
Note that this is approximately O(N**2) and that it hammers Google servers. However it has the benefit that if a user enters just one url we can find all the other urls. It would be _very_ useful if the SGApi could do this and expose it as one call.
> On Sun, Jul 13, 2008 at 9:25 AM, Ade Oshineye <a...@google.com> wrote:
>> Are these links meant to be bi-directional? >> The following 2 urls give different results implying that the SGApi >> can only follow links between accounts and doesn't infer >> relationships:
> ... though I'm curious what you mean by "doesn't infer relationships".
> So if you start there, it's a dead-end. What would you expect it to do? (I > do plan to add a fuzzy=1 option in the future, where if a node is > uncontested we could walk up the me edge in the wrong direction. Fuzzy mode > would only be for when human reviewers are involved.)
>> 2008/7/12 Brad Fitzpatrick <bradf...@google.com>: >> > The Social Graph API was launched February 1st right before the Social >> > Graph >> > Foo Camp. The main Foo Camp starts today, so this seems like a good >> > time to >> > launch some more SGAPI features.
>> > So far the Social Graph API has only had 1 method (/lookup) and 1 other >> > debug method (/testparse). Now there's the first new high-level API, >> > "otherme".
>> > No docs are written yet, so consider this a sneak preview if you'd like:
>> > q - comma-separated list of URLs/emails that a user has said are theirs >> > jscb - JSON-P callback, optional. >> > pretty - optional boolean: pretty-print >> > sgn - optional boolean: include sgn canonicalizationd details/nodes >> > (including sgn mboxsha1sum nodes)
>> > Response is all the other URLs that user has, not including the one or >> > more >> > you passed in in the 'q' parameter. They're keyed by URL and include >> > all >> > the new attributes that are being parsed (name, photo, rss, atom, etc).
>> > Note that this is simply a mechnical transformation on the /lookup >> > method, >> > not offering anything that wasn't possible before. It's just that the >> > transformation was tedious and error-prone and silly to have to repeat >> > in >> > each client library. Hopefully putting it in the server makes it more >> > convenient for everybody.
>> > Why is this useful? A lot of websites are now letting you list your >> > other >> > websites/profiles on your profile, but it's just as annoying to repeat >> > this >> > information on every site as it is to redefine your friends everywhere. >> > If >> > the site incrementally hits this API in the background as you enter >> > profile >> > URLs, the site can then recommend you link/share your other websites. >> > Examples of sites that let you enter your other profile URLs and could >> > use >> > this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, >> > Friendfeed, Mugshot. And that's just off the top of my head from sites >> > I'm >> > familiar with. I'm sure there's a bunch more.
>> > (Also new: Google Profiles[1] data is now served live, rather than from >> > crawl data. It'd be nice to do this optionally also for other willing >> > sites >> > in the future so I did Google Profiles as an experiment and to setup the >> > infrastructure for it.)
>> > Docs to come soon. Let me know if there's any questions/requests in the >> > meantime.
On Mon, Jul 14, 2008 at 9:45 AM, Ade Oshineye <a...@google.com> wrote:
> At the moment any tool based on the idea that the user enters some of > their urls and the system works out their urls will still have to > implement something like the following algorithm:
The "otherme" method takes a list of URLs already. I'm not sure why you'd need the code below.
> while len(urlsToVisitSet) > 0: > for url in urlsToVisitSet.copy(): > #network call to sgapi > fetchedUrlsSet = fetchOtherUrls(url) > visitedUrlsSet.add(url) > for fetchedUrl in fetchedUrlsSet: > if fetchedUrl not in visitedUrlsSet: > urlsToVisitSet.add(fetchedUrl) > userUrlsSet = userUrlsSet.union(fetchedUrlsSet)
> Note that this is approximately O(N**2) and that it hammers Google servers. > However it has the benefit that if a user enters just one url we can > find all the other urls. It would be _very_ useful if the SGApi could > do this and expose it as one call.
> 2008/7/14 Brad Fitzpatrick <bradf...@google.com>: > > On Sun, Jul 13, 2008 at 9:25 AM, Ade Oshineye <a...@google.com> wrote:
> >> Are these links meant to be bi-directional? > >> The following 2 urls give different results implying that the SGApi > >> can only follow links between accounts and doesn't infer > >> relationships:
> > ... though I'm curious what you mean by "doesn't infer relationships".
> > There are no me links from bradfitz.jaiku.com:
> > So if you start there, it's a dead-end. What would you expect it to do? > (I > > do plan to add a fuzzy=1 option in the future, where if a node is > > uncontested we could walk up the me edge in the wrong direction. Fuzzy > mode > > would only be for when human reviewers are involved.)
> >> 2008/7/12 Brad Fitzpatrick <bradf...@google.com>: > >> > The Social Graph API was launched February 1st right before the Social > >> > Graph > >> > Foo Camp. The main Foo Camp starts today, so this seems like a good > >> > time to > >> > launch some more SGAPI features.
> >> > So far the Social Graph API has only had 1 method (/lookup) and 1 > other > >> > debug method (/testparse). Now there's the first new high-level API, > >> > "otherme".
> >> > No docs are written yet, so consider this a sneak preview if you'd > like:
> >> > q - comma-separated list of URLs/emails that a user has said are > theirs > >> > jscb - JSON-P callback, optional. > >> > pretty - optional boolean: pretty-print > >> > sgn - optional boolean: include sgn canonicalizationd details/nodes > >> > (including sgn mboxsha1sum nodes)
> >> > Response is all the other URLs that user has, not including the one or > >> > more > >> > you passed in in the 'q' parameter. They're keyed by URL and include > >> > all > >> > the new attributes that are being parsed (name, photo, rss, atom, > etc).
> >> > Note that this is simply a mechnical transformation on the /lookup > >> > method, > >> > not offering anything that wasn't possible before. It's just that the > >> > transformation was tedious and error-prone and silly to have to repeat > >> > in > >> > each client library. Hopefully putting it in the server makes it more > >> > convenient for everybody.
> >> > Why is this useful? A lot of websites are now letting you list your > >> > other > >> > websites/profiles on your profile, but it's just as annoying to repeat > >> > this > >> > information on every site as it is to redefine your friends > everywhere. > >> > If > >> > the site incrementally hits this API in the background as you enter > >> > profile > >> > URLs, the site can then recommend you link/share your other websites. > >> > Examples of sites that let you enter your other profile URLs and could > >> > use > >> > this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, > >> > Friendfeed, Mugshot. And that's just off the top of my head from > sites > >> > I'm > >> > familiar with. I'm sure there's a bunch more.
> >> > (Also new: Google Profiles[1] data is now served live, rather than > from > >> > crawl data. It'd be nice to do this optionally also for other willing > >> > sites > >> > in the future so I did Google Profiles as an experiment and to setup > the > >> > infrastructure for it.)
> >> > Docs to come soon. Let me know if there's any questions/requests in > the > >> > meantime.
Brad Fitzpatrick wrote: > The "otherme" method takes a list of URLs already. I'm not sure why > you'd need the code below.
The original service accepts multiple URLs and has the fme (follow "me" links) argument. I'm still unclear as to how this "otherme" query differs from "lookup".
On Tue, Jul 15, 2008 at 1:38 PM, Dale Newfield <D...@newfield.org> wrote:
> Brad Fitzpatrick wrote: > > The "otherme" method takes a list of URLs already. I'm not sure why > > you'd need the code below.
> The original service accepts multiple URLs and has the fme (follow "me" > links) argument. I'm still unclear as to how this "otherme" query > differs from "lookup".
As I said in my email, it's the same data, organized differently. It also de-dups stuff using ident_is and pk_is attributes (only visible in lookup's sgn=1 mode). That is, if fme=1 would both my sgn://myspace.com/?pk=123 and sgn://myspace.com/?ident=bradfitz nodes, and those were known to be identical, the otherme API combines those.
It's basically just an easier way to access the data when that's the exact question you want to see answered (Given some URLs, what are the other ones?) without walking the often-nasty data structure that is returned by lookup.
the problem is that its over 95% wrong results. (the other URLs are
not other locations for Richard Cyganiak) . My question is pretty
general, what would you says are the top causes for these false
positives.
Giovanni
On Jul 12, 12:04 am, "Brad Fitzpatrick" <bradf...@google.com> wrote:
> The Social Graph API was launched February 1st right before the Social Graph
> Foo Camp. The main Foo Camp starts today, so this seems like a good time to
> launch some more SGAPI features.
> So far the Social Graph API has only had 1 method (/lookup) and 1 other
> debug method (/testparse). Now there's the first new high-level API,
> "otherme".
> No docs are written yet, so consider this a sneak preview if you'd like:
> q - comma-separated list of URLs/emails that a user has said are theirs
> jscb - JSON-P callback, optional.
> pretty - optional boolean: pretty-print
> sgn - optional boolean: include sgn canonicalizationd details/nodes
> (including sgn mboxsha1sum nodes)
> Response is all the other URLs that user has, not including the one or more
> you passed in in the 'q' parameter. They're keyed by URL and include all
> the new attributes that are being parsed (name, photo, rss, atom, etc).
> Note that this is simply a mechnical transformation on the /lookup method,
> not offering anything that wasn't possible before. It's just that the
> transformation was tedious and error-prone and silly to have to repeat in
> each client library. Hopefully putting it in the server makes it more
> convenient for everybody.
> Why is this useful? A lot of websites are now letting you list your other
> websites/profiles on your profile, but it's just as annoying to repeat this
> information on every site as it is to redefine your friends everywhere. If
> the site incrementally hits this API in the background as you enter profile
> URLs, the site can then recommend you link/share your other websites.
> Examples of sites that let you enter your other profile URLs and could use
> this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo,
> Friendfeed, Mugshot. And that's just off the top of my head from sites I'm
> familiar with. I'm sure there's a bunch more.
> (Also new: Google Profiles[1] data is now served live, rather than from
> crawl data. It'd be nice to do this optionally also for other willing sites
> in the future so I did Google Profiles as an experiment and to setup the
> infrastructure for it.)
> Docs to come soon. Let me know if there's any questions/requests in the
> meantime.
Without knowing what the right data is, I can't answer. But I can recommend that you can debug this yourself by using the /lookup API instead and seeing the raw data from which the /otherme data is calculated:
> the problem is that its over 95% wrong results. (the other URLs are > not other locations for Richard Cyganiak) . My question is pretty > general, what would you says are the top causes for these false > positives.
> Giovanni
> On Jul 12, 12:04 am, "Brad Fitzpatrick" <bradf...@google.com> wrote: > > The Social Graph API was launched February 1st right before the Social > Graph > > Foo Camp. The main Foo Camp starts today, so this seems like a good time > to > > launch some more SGAPI features.
> > So far the Social Graph API has only had 1 method (/lookup) and 1 other > > debug method (/testparse). Now there's the first new high-level API, > > "otherme".
> > No docs are written yet, so consider this a sneak preview if you'd like:
> > q - comma-separated list of URLs/emails that a user has said are theirs > > jscb - JSON-P callback, optional. > > pretty - optional boolean: pretty-print > > sgn - optional boolean: include sgn canonicalizationd details/nodes > > (including sgn mboxsha1sum nodes)
> > Response is all the other URLs that user has, not including the one or > more > > you passed in in the 'q' parameter. They're keyed by URL and include all > > the new attributes that are being parsed (name, photo, rss, atom, etc).
> > Note that this is simply a mechnical transformation on the /lookup > method, > > not offering anything that wasn't possible before. It's just that the > > transformation was tedious and error-prone and silly to have to repeat in > > each client library. Hopefully putting it in the server makes it more > > convenient for everybody.
> > Why is this useful? A lot of websites are now letting you list your > other > > websites/profiles on your profile, but it's just as annoying to repeat > this > > information on every site as it is to redefine your friends everywhere. > If > > the site incrementally hits this API in the background as you enter > profile > > URLs, the site can then recommend you link/share your other websites. > > Examples of sites that let you enter your other profile URLs and could > use > > this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, > > Friendfeed, Mugshot. And that's just off the top of my head from sites > I'm > > familiar with. I'm sure there's a bunch more.
> > (Also new: Google Profiles[1] data is now served live, rather than from > > crawl data. It'd be nice to do this optionally also for other willing > sites > > in the future so I did Google Profiles as an experiment and to setup the > > infrastructure for it.)
> > Docs to come soon. Let me know if there's any questions/requests in the > > meantime.
|
