Facebook Graph Search: I got it, I even queried the author – but I don’t get it yet

Facebook’s new graph search is in closed beta at the moment.  I managed to hurl myself onto it  before the door shut.   I played around with it for a while, then I stopped, waiting for inspiration about how to make it as interesting for me as I was sure it was going to be.  I  haven’t figured it out yet.   So when I saw that the lead engineer from Graph Search, Kari Lee, was giving a Facebook Tech Talk this evening at Facebook’s London office, I hurled myself at the guest list, and squished myself on before the door shut.

My problem is not that I’m uninterested in graph search.  I think it’s fascinating.  Honest.  I even know more than a bit about it, and I still think it’s fascinating.   And I am convinced that for Facebook, the potential here is huge.  Beyond huge.  I am pre-sold on that.   It’s just that, as currently constituted, Facebook’s beta version doesn’t do anything for me.   I do wonder occasionally what I should ask of it.  And fail to engage myself.  Then I try not to be parochial and I think of myself as not being myself, but being at different life stages, doing and wanting different things.  So far, it hasn’t helped.

Facebook’s graph search icon

Facebook’s previous version of search was awful.   I blamed this on Bing, rightly or wrongly.  So, with graph search, I was looking forward to seeing something that shone a headlamp into the murk of the future, even if it what was illuminated wasn’t already a polished jewel.

The content of the talk this evening focussed almost entirely on the natural language processing done by the query constructor, which is impressively free form, and does a lot of “search ahead”, which, given the nature of the data it is trying to reach, is not trivial.  It’s all also updated in real time.   A lot of heavy lifting had clearly been done: they showed a picture of Kari’s team fillling up a massive “statement” staircase.  Mention was also made of how the indexes were stored.  I did wonder how much sense the talk made to much of the audience, as the majority had not been able to cram themselves onto the beta – possibly because they were ineligible as they spoke UK-english, which is not yet supported.  (I’m not sure how or why FB inferred that I spoke US English as one of my dialects.)

Kari went into considerable detail about their strategy and approach for query NLP and UI.  But, to my mind, the talk wasn’t about graph search.   I really thought it was about a front end to graph search.  I asked her about this, as best I could.  I thought she was treating the problem as if it was entirely about query resolution, and the problem ended there.  She answered that what she did was the parser, and that was what she talked about.   Which was certainly a straightforward and honest answer, but it left me feeling rather puzzled.  I think the good bit’s the next bit.  And by that I do not mean the cleverness of how it’s all distributed.   I mean what it does.

Facebook clearly are into graphs from an algorithmic perspective.   That was, in a way, the subject of their recent Kaggle competition which they are using to try to hire more data scientists.  So my bet is that someone, somewhere inside Facebook is thinking about it.  It just hasn’t been surfaced yet.   Graph search, as it was presented this evening,  is already being used internally in Facebook, in two products (ie. services) currently in development.    So we’ll see more of it.   Perhaps what it most needs is a context.  So I look forward to seeing more about how that develops.

[You may have noticed a recent blog theme of “stuff I see while wandering around London at night”.   (You’d be right…:-)]

Looking forward to speaking about discovery-driven design at Strata next week…..

But I’m having a tough time working out the rest of my conference schedule! Triple booked myself at least twice.

Exploiting competitor information via the Facebook API

Interesting day at Facebook’s London Mobile Hack yesterday.   Disclosure:  I  skipped the hack part, which was scheduled for 5pm to 9.30pm.  But I attended a full day of lectures before I snuck off.  So I hope I can wear the t-shirt without shame.

At one point I asked Simon Cross (who built the Graph Explorer) about the relationship between:

• the custom actions you can create, make available for users to perform,  record inside Facebook on the users’ Graph, and make available for publication to your users’ TimeLines, Tickers and Newsfeeds (subject to Facebook’s algorithmic discretion, and subject to the user having granted your app the requisite write permissions)

and

• the fine-grained activity permissions that users grant to applications, which you can inspect (and troubleshoot) via Graph Explorer

I wasn’t really sure why I was asking the question – I just had a nagging feeling I was missing something.  I didn’t understand how custom actions, which are extensible, were related to activity permissions which were (presumably but not necessarily) defined in the same way (but not necessarily set to the same value) for every app.

In retrospect I was just confused.   My thinking now is that there is no necessary relationship.  The custom actions which are graph extensions occur as a combination of app design, Facebook approval, then, at run time, are instantiated and populated via user agency occurring via the app.  These custom user actions doesn’t necessarily have any link to the FB app action permission schema,  although they of course might have a link if the app action involved actually involves, at a more abstract level, any of the types of actions which occur in the permission schema.  Ok well that’s sorted then.    Maybe.  Unless I’m actually wrong here, which of course I might be.  In which case tell me.

Setting aside for the moment whatever ontological muddles I might have gotten into,  the answer I got from Simon was, I think, much more interesting than the question I asked.   What he said was that subject to the appropriate permissions having been granted by the user, it was possible for an app to read data stored in the user’s graph by other apps.    He explained that this was because Facebook viewed all data as the user’s data, and it was, therefore, for the user to decide who could view it.

Here’s an example which I just fished out of the docset:

“If the user has granted your app with the user_games_activity permission then this api will give you scores for all apps for that user. Otherwise it will give you scores only for your app.”  (source:  https://developers.facebook.com/docs/reference/api/user/#friends accessed 13.34 GMT 6 March 2012)

This has a variety of interesting potential uses, which I am sure you are busy thinking about right this minute.

Of course – what’s sauce for the goose is sauce for the gander.   If the user has granted permission, you can see the trail other apps have left, but other apps will be able see what YOU have salted away in the graph, too.