Skip to content

CamliLODstore: a Linked Open Data Camlistore

January 31, 2011

When Alex told me about Pubsubhubbub (PuSH), I agreed that it had enormous potential to work with the Semantic Web stack. As a result of that chat, we created sparqlPuSH (winner of SFSW challenge at ESWC’2010). The basic idea there is to keep SPARQL endpoints up to date by distributing changes via PuSH. Now the PuSH guys came up with Camlistore. And guess what? It gives me another idea. 🙂

Camlistore (an acronym for “Content-Addressable Multi-Layer Indexed Storage”) is a work-in-progress “way to store, sync, share, model and back up content.” They have a focus on content-addressable storage and separate interoperable parts (storagesyncsharingmodeling), with well-defined protocols and roles. [Update: A good summary in this presentation and more recently this presentation in São Paulo by Brad Fitzpatrick.]

My idea? Camlistore sounds like a slice of goodness that mashes up nicely with Linked Open Data (LOD) stores.

  • addressable: data in Camlistore can be addressed  by content – via hashes (blobref), and a permanode keeps a URI-worthy stable identifier.
  • storage: put RDF graphs as camli objects in Camlistore. The best granularity needs a bit more thinking. Each triple as an object, or a collection of triples as an object?
  • sync: apps can have their own copy of (a section of) the Web of Data in their local CamliLODstore. They can query the data within their own server (faster) and when some change happens, Camlistore makes the sync. “While multiple users may collaborate on mutating an object, he owner ultimately decides the policies on how the mutations are respected.”
  • sharing: Camlistore’s auth scheme sounds like it would be directly applicable to the LOD case. “You create a claim that a user has access to something, and then your blobserver’s public frontend authenticates (if applicable) a remote user and gives them access as permitted by your claim.”
  • model: “Camlistore doesn’t care what you put in it (everything is just dumb bytes) and you’re free to adopt your own data model.” This needs more thinking, but at first sight it seems that: camli permanode blobrefs = URIs; camli objects = RDF graphs; camli blobs = literals; camli blobrefs = RDF property values.
  • query: Camlistore does not seem to discuss query capabilities yet. I can see a SPARQL endpoint running on top of a Camlistore, exposing its data on the Web, benefiting from its authentication features, and keeping the data up to date via the synchronization features.

Anybody out there with time to experiment with this CamliLODstore idea?

  1. Nice article. Please come join the mailing list so we can talk about these use-cases more!

  2. Camlistore and your CamliLODstore proposal sounds quite interesting. As far as I get the idea behind Camlistore, one would simple put the schema (especially RDF Model, RDF Schema etc.) in a blob and describe it on top of JSON. So we need at least to use one RDF/JSON serialization format, or even better a RDF/JSON standard serialization format (which will hopefully be a deliverable of the new RDF WG).
    Would be nice, if we could push this porposal a bit forward 😉

    • (Sorry for the delayed approval. Somehow missed this.)

      Sure. It may get more involved than just putting the schema in a blob if we want to share things in the granularity of triples, retain ability to query/search for objects given the schema, etc.

      But, as you say, I’m up for pushing the proposal forward!

Trackbacks & Pingbacks

  1. Tweets that mention CamliLODstore: a Linked Open Data Camlistore « Pablo Mendes --

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: