From W3C Wiki
Back to pushback home
See also: Fusion (how to generate RDForms)
RDForms: pushback - Write Data Back From RDF to Non-RDF Sources
We introduce the basic terms used here and try to come up with some definitions (Note: this section needs heavy review and copy-editing - feel free to edit and don't forget to put yourself to the contributors list on the top of the page ;).
In the context of pushback, an RDForm is:
- an (X)HTML form form decorated with RDFa using the RDForms vocabulary as defined below, which has been
- dynamically generated from an RDF graph in a document (which in turn might be the result of a merge, smush or whatever operation) and an existing (X)HTML form for the data present in the graph (aka fusion).
Example: an RDForm to edit information about a person could look like the following.
<form id="personform" action="" about="#form1" typeof="pb:RDForm"> <div rel="pb:operation"> <div about="#crud-op1" typeof="pb:CRUDOperationDELETE"> <span rel="pb:onField" resource="#form1.field1" /> </div> </div> <fieldset> <legend>Person</legend> <div rel="pb:field"> <div about="#form1.field1" typeof="pb:UpdateableField"> <label rel="pb:key" resource="#form1.field1.key">Name</label>: <div rel="pb:value"> <div about="#form1.field1.value" typeof="pb:FieldValue"> <input type="text" id="person-name" property="rdf:value" content="Jason Dunno" value="Jason Dunno" /> </div> </div> </div> </div> </fieldset> </form>
The following RDF graph (in Turtle syntax) is embedded in the RDForm above:
:form1 a pb:RDForm ; pb:operation :crud-op1 ; pb:field form1.field1 . :crud-op1 a pb:CRUDOperationDELETE ; pb:onField :form1.field1; :form1.field1 a pb:UpdateableField. pb:key :form1.field1.key ; pb:value :form1.field1.value . :form1.field1.value a pb:FieldValue; rdf:value "Jason Dunno".
Each field in an HTML form can be understood as a key/value pair (KVP). A field in an RDForm is hence:
- A part of an RDForm, which consists of a
- KVP record containing a key that identifies the field and a value that carries the field value.
Example: an RDForm field might be a text field containing the name of a person:
field: person-name key: person-name-key value: 'Ronald D. Friendly'
C(R)UD Operations and Binding to Fields
On each RDForm field one or more CRUD operation, such as add a field or remove a field, may be permitted. In RDForms we care about 'writing' wrapped Web 2.0 sources, hence it is really CUD (but to remember where this comes from, we write C(R)UD ;)
In order to understand which C(R)UD operation is allowed and intended on which RDForm field, we must flag it somehow. The process of defining which C(R)UD operation should be applied on which field(s) is called binding in RDForms. For further details how this is represented, see the RDForms vocabulary, below.
A C(R)UD operation in RDForms hence is defined as:
- A declaration of an intended operation on an RDForm field, where
- an operation is one of the following: CREATE, UPDATE or DELETE as defined in the RDForms vocabulary, along with
- a binding to an RDForm field, which defines to which field the operation applies.
Example: Let us assume we want to declare that the field
person-name from above shall be deleted on form submission. We would hence say:
crud operation: DELETE perform operation on field: person-name
What follows is an overview of HTML forms and their possible fields and how they map to XML Schema data types.
Using Wikipedia's HTML form article as a base, we identify the following field types as relevant for RDForms:
- input field
- textarea: like the text input field, except a textarea allows for multiple rows of data to be shown and entered
- select: a drop-down list that displays a list of items a user can select from
Field Value Mapping
In RDForms, we define the following mapping of HTML form field types to (primitive) XML schema data types (string, boolean, list of strings, etc.):
|HTML form field type|
The core pattern of the RDForms straw man proposal for decorating HTML form field values and connecting the so created fields with intended C(R)UD operations looks as follows:
?rdform rdf:type pb:RDForm ; pb:operation ?crudop ; pb:field ?field ; ?field rdf:type pb:UpdateableField . ?crudop rdf:type pb:CRUDOperation ; pb:onField ?field .
Where the allowed types (rdfs:subClass of pb:CRUDOperation) for
The current (straw man proposal for the) RDForms vocabulary at a glance looks as follows (automatically generated by Neologism):
One example is a simple Twitter delete pushback (via bookmarklets) allowing to add Twitter statuses and remove them (for an example account;) based on an RDF graph that represents each Twit as a sioc:BoardPost.
... twitterformrdf .prefix('rdf', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#') .prefix('pb', 'http://ld2sd.deri.org/pb/ns#') .prefix('dcterms', 'http://purl.org/dc/terms/') .where('?rdform rdf:type pb:RDForm') .where('?rdform pb:operation ?crudop') .where('?rdform pb:field ?field') .where('?field rdf:type pb:UpdateableField') .where('?crudop pb:onField ?field') .where('?crudop rdf:type ?crudoptype') .where('?field pb:key ?key') .where('?field dcterms:title ?title') .where('?field pb:value ?val') .where('?val rdf:value ?fval') ...
Example: Bugtracking System
Another example for pushback is a Jira a bug tracking application. Below, you see a screen shot from the working Jira pushback demo (a screen cast and a live demo at ld2sd.deri.org to follow soon; meanwhile you can test it yourself with the code from the Google code repository):