Flock browser RDF: describing accounts

Flock is a mozilla-based browser that emphasises social and “web2” themes. From a social-network-mobility thread, I’m reminded to take another look at Flock by Ian McKellar’s recent comments…

I wrote a bunch of that code when I was at Flock.

It’s all in RDF, I think it’s currently in a SQLite triple store in the user’s profile directory

I took a look. Seems not to be in SQLite files, at least in my fresh installation. Instead there is a file flock-data.rdf which looks to be the product of Mozilla’s ageing RDF engine. I had to clean things up slightly before I could process it with modern (Redland in this case) tools, since it uses Netscape’s pre-RDFCore datatyping notation:

cat flock-data.rdf | sed -e s/NC:parseType/RDF:datatype/

With that tweak out of the way, I can nose around the data using SPARQL. I’m interested in the “social graph” mobility discussions, and in mapping FOAF usage to Brad Fitzpatrick’s model (see detail in his slides).

The model in the writeup from Brad and David Recordon has nodes (standing roughly for accounts) and “is” relations amongst them where two accounts are known to share an owner, or “claims” relations to record a claim associated with one such account of shared ownership with another.

For example in my Flickr account (username “danbri”) I might claim to own the del.icio.us account (also username “danbri”). However you’d be wise not to believe flickr-me without more proof; this could come from many sources and techniques. Their graph model is focussed on such data.

FOAF by contrast emphasises the human social network, with the node graph being driven by “knows” relationships amongst people. We do have the OnlineAccount construct, which is closer to the kind of nodes we see in the “Thoughts on the Social Graph” paper, although they also include nodes for email, IM and hashed mailbox, I believe. The SIOC spec elaborates on this level, by sub-classing its notion of User from OnlineAccount rather than from Person.

So anyway, I’m looking at transformations between such representations, and FLock seems a nice source of data, since it watches over my browsing and when I use a site it knows to be “social”, it keeps a record of the account in RDF. For now, here’s a quick query to give you an idea of the shape of the data:

PREFIX fl: <http://flock.com/rdf#>
PREFIX nc: <http://home.netscape.com/NC-rdf#>
FROM <flock-data-fixed.rdf>
?x fl:flockType “Account” .
?x nc:Name ?name .
?x nc:URL ?url .
?x fl:serviceId ?serviceId .
?x fl:accountId ?accountId .

Running this with Redland’s “roqet” utility in JSON mode gives:

“head”: {
“vars”: [ “x”, “name”, “url”, “serviceId”, “accountId” ]
“results”: {
“ordered” : false,
“distinct” : true,
“bindings” : [
“x” : { “type”: “uri”, “value”: “urn:flock:ljdanbri” },
“name” : { “type”: “literal”, “value”: “danbri” },
“url” : { “type”: “literal”, “value”: “http://www.livejournal.com/portal” },
“serviceId” : { “type”: “literal”, “value”: “@flock.com/people/livejournal;1” },
“accountId” : { “type”: “literal”, “value”: “danbri” }
“x” : { “type”: “uri”, “value”: “urn:typepad:service:danbri” },
“name” : { “type”: “literal”, “value”: “danbri” },
“url” : { “type”: “literal”, “value”: “http://www.typepad.com” },
“serviceId” : { “type”: “literal”, “value”: “@flock.com/blog/typepad;1” },
“accountId” : { “type”: “literal”, “value”: “danbri” }
“x” : { “type”: “uri”, “value”: “urn:flock:flickr:account:35468151816@N01” },
“name” : { “type”: “literal”, “value”: “danbri” },
“url” : { “type”: “literal”, “value”: “http://www.flickr.com/people/35468151816@N01/” },
“serviceId” : { “type”: “literal”, “value”: “@flock.com/?photo-api-flickr;1” },
“accountId” : { “type”: “literal”, “value”: “35468151816@N01” }
“x” : { “type”: “uri”, “value”: “urn:wordpress:service:danbri” },
“name” : { “type”: “literal”, “value”: “danbri” },
“url” : { “type”: “literal”, “value”: “http://www.wordpress.com” },
“serviceId” : { “type”: “literal”, “value”: “@flock.com/people/wordpress;1” },
“accountId” : { “type”: “literal”, “value”: “danbri” }
“x” : { “type”: “uri”, “value”: “urn:flock:youtube:modanbri” },
“name” : { “type”: “literal”, “value”: “modanbri” },
“url” : { “type”: “literal”, “value”: “http://www.youtube.com/profile?user=modanbri” },
“serviceId” : { “type”: “literal”, “value”: “@flock.com/?photo-api-youtube;1” },
“accountId” : { “type”: “literal”, “value”: “modanbri” }
“x” : { “type”: “uri”, “value”: “urn:delicious:service:danbri” },
“name” : { “type”: “literal”, “value”: “danbri” },
“url” : { “type”: “literal”, “value”: “http://del.icio.us/danbri” },
“serviceId” : { “type”: “literal”, “value”: “@flock.com/delicious-service;1” },
“accountId” : { “type”: “literal”, “value”: “danbri” }

You can see there are several bits of information to squeeze in here. Which reminds me to chase up the “accountHomepage” issue in FOAF. They sometimes use a generic URL, eg. http://www.livejournal.com/portal, while other times an account-specific one, eg. http://del.icio.us/danbri. They also distinguish an nc:Name property of the account from a fl:accountId, allowing Flickr’s human readable account names to be distinguished from the generated ID you’re originally assigned. The fl:serviceId is an internal software service identifier it seems, following Mozilla conventions.

Last little experiment: a variant of the above query, but using CONSTRUCT instead of SELECT, to transform into FOAF’s idiom for representing accounts:

?x a foaf:OnlineAccount .
?x foaf:name ?name .
?x foaf:accountServiceHomepage ?url .
?x foaf:accountName ?accountId .

Seems to work… There’s load of other stuff in flock-data.rdf too, but I’ve not looked around much. For eg. you can search tagged URLs –

WHERE {[fl:tag “funny”; nc:URL ?url]}

Published by danbri

Click here to type

Join the Conversation


  1. Dan,
    Flock 0.9.1 still uses RDF/XML. Flock 1.0, soon available in private beta [1], uses RDF in SQLite as Ian mentioned.

    Most of the “schema” used in flock-data.rdf can be found in favorites-coop.js [2], which is the abstraction layer Ian wrote a while back.

    I’m interested in learning what other information you or others might find useful in our objects, what uses outside of Flock you see for the types of data stored in flock-data.rdf, and how you see things like the FOAF spec and XMPP fitting in with all of this.

    -lilmatt [3]

    [1] http://www.flock.com/privatebeta
    [2] http://tinyurl.com/29zx6r
    [3] http://weblogs.mozillazine.org/lilmatt/

  2. I’m glad you found my comment useful and I’m glad lilmatt was able to fill you in on the current status of that code.

    It’s all generated out of the abstraction layer that Matt alluded to, an ORM-like library that maps between JS objects and RDF assertions. As a result the RDF tends to look like a bunch of serialized objects rather than a nicely designed interoperable schema :)

    Also, since the library evolved from a very simple hack basically written on a bet into the core of a fairly complex product the schema language really sucks. I’d looked at rewriting it to store its schema in RDF (probably as a slightly extended subset of RDFS and OWL) but then there was a product to ship so I never got a chance. My most recent attempts at rewriting it (which are sadly about six months old) head in that direction a little.

    Early on at Flock I was interested in using FOAF to model people (since I’d looked at a bit in the past) but our requirements were different enough that we didn’t end up going that way.

    I think social network aware client software like Flock will be important in the social network portability game. There’s a lot of public data out there but there’s also a lot that isn’t accessible except to users who are logged in. That’s one of the reasons I was excited to build Flock in the first place :)


Leave a comment