If you’re familiar with MVC design, or at least with Ruby on Rails, then you’ve heard of CRUD: create, read, update, delete. These are the basic operations that are possible for data. There are various ways to do each of them, but these four are at the heart of any data-driven web application.
The Fabulator is a data-driven web application engine, so it makes sense that it should support the four CRUD operations. Since the database is essentially an RDF model, we need to map CRUD to RDF.
Fabulator applications are essentially XML documents describing what the application should do. Associated with the applications are page parts (Radiant is the host CMS) that are rendered if the application is in the state for that part. The application is just a document in a CMS.
Since Fabulator applications are XML documents, we want an XML way of doing each of the CRUD operations using template languages such as TAL as examples. For this, we have a series of operations that take an RDF template (we can call this a sketch) with placeholders representing data in the application context.
Reading
To read from an RDF model, we simple provide a sketch of what the RDF graph should look like and put our variable names where we want the corresponding RDF data to be accessible in the application views (anything prefixed with ? is considered a variable name here). Some of the details will probably change as we get some examples up and running, but the following snippet gives the flavor of what we intend to do.
Creating and Updating
Since objects are automagically created if they don’t already exist, creating and updating are synonymous in RDF. In this case, we use rdf-assertion instead of rdf-query to change from reading to writing. We are documenting a truth. Substitutions from the application context are the same as for reading. To the extent that we can, the semantics of the two operations will be identical except for the direction of data flow.
Deleting
Objects don’t really exist in RDF unless there’s something to say about them, so objects will disappear when there’s nothing associated with them. Deleting all information about an object will remove it from the RDF model.
Again, changing a rdf-assertion element to a rdf-denial element will remove any information that was added by the rdf-assertion (assuming an identical context).
Changing Application State
Besides the CRUD operations, we need a way to change the state of the application based on the information in the RDF model and the application context. For this, we have rdf-assert and rdf-deny that will take a sketch of what we expect to have (or not have) in the model. If the match succeeds (or fails), we change to the corresponding state and proceed.
This can be used to initialize an application to a particular start state based on information we already have, or change which state is next based on the information we already have.
Leave a comment