From W3C Wiki

This is a community project to develop a method (vocabulary+API) to push back data from RDF data sources to non-RDF data sources such as Web 2.0 APIs (flickr, microblogging systems, etc.).

pushback - Write Data Back From RDF to Non-RDF Sources

Use Cases | RDForms | Fusion | Authentication | Authorisation | Code (DOAP) | Demos



The idea might be around a bit longer, for sure, but the first trace I was able to find was at VoCamp Galway in late 2008. Then, after some time, the issue has been picked up on #swig channel (03/2009), where TimBL stated: Tabulator can write back to DBpedia. It is DBpedia's job to take the change and apply it to Wikipedia. While we can say that for a fixed schema the act of writing back stuff to the non-RDF is sensible and feasible, one has to question if this is the case for, e.g. Wikipedia as well. However, when assuming that an RDF wrapper already exists exposing structured data from a Web 2.0 source such as Twitter, flickr, etc. as linked data on the Web, hence knows about the Web 2.0 read-interface, one can assume that this RDF wrapper should in theory be able to handle the write-interface as well. What is indeed needed is a method to tell the RDF wrapper which parts of the graph to update (so called updateable parts) and what CRUD operations are allowed on a certain resource.

Read more about the relation of pushback regarding SPARQL Update and direct Web 2.0 API/REST calls or view a short screen cast introducing pushback and RDForms incl. a demo of it (less than 10min in total, demo starts around 3min 30sec).

Rules of Engagement

You're welcome to contribute. This is a Web of Data community project; how ever, please keep in mind to:

  1. Add your name to the interested people section at the bottom of this page, incl. the area you are interested
  2. If not yet done, subscribe to public-lod@w3.org, we gonna discuss there
  3. Usually, discussions take place on IRC #swig channel, but you may also subscribe to the identi.ca RDForms group
  4. As a community project, the results created herein are licensed under a Creative Commons Attribution 3.0 License, for the software bits we have to decide on (1) where to put it (maybe Google code?) and (2) under which license we make it available

Use Cases

See the use case page for a collection of use cases for pushback. Please add your own!

Work Plan

  • extend and detail out the use cases
  • DONE: review Jeni Tennison's rdfquery
  • DONE: review existing HTML forms and their applications and detect common patterns
  • review existing Web 2.0 APIs (such as flickr, Twitter, etc.) and detect common patterns
  • DONE: evaluate what Changeset and Service Schema can contribute
  • PROPOSAL: develop a vocabulary that captures the key/value pairs of each field in the form
  • PROPSAL: develop the fusion, that is the process of creating an RDForm given an HTML form and RDF data from a non-RDF data source
  • PROPOSAL: collect requirements for authentication and select from existing solutions such as FOAF+SSL, OAuth, OpenID, etc. that allow the update of Web 2.0 APIs
  • PROPOSALS: implement a demo based on the above for one use case, for example, bugtracking


Results from the design (brainstorming) session (cygri and mhausenblas, 2009-01-03) have been captured on flickr. Here is the resulting overall architecture:

Design pillars:

  • Deployment and invocation of a pushback (a bookmarklet triggering an inline overlay container that loads an RDForm)
  • RDForms - RDFa for marking up HTML forms along with a vocabulary to capture updateable parts and allowed CRUD operations and a process to create these RDForms on-the-fly (called fusion)
  • a mechanism defining how the User Agent interacts with the pushback controller (due to XSS needed) and how the pushback controller interacts with the RDF wrapper (which knows how to handle the origin, non-RDF data source write-API)
  • authentication for handling write operations on the origin, non-RDF data source write-API


  1. user loads RDF document using some domain vocabulary in an Web of Data browser such as Tabulator;
  2. user activates RDForms via bookmarklet;
  3. fusion engine takes HTML form (derived from same non-RDF data source as the RDF document, hence corresponding elements) and a mapping from the domain vocabulary to RDForms vocabulary to generate an RDForms on-the-fly;
  4. RDForms parser executes the desired operation if user is accordingly authenticated
  5. changes transferred to pushback controller (due to XSS restrictions) based on a simple REST-interface;
  6. pushback controller relays changes to RDF write-wrapper


People Interested in the Area