Rest and Object Orientation via OWL

I just came across a promising article REST versus Object-Orientation via a post by Tim Bray.

Benjamin Carlyle captures many of the things I discovered whilst using RDF in my implementation of BlogEd 0.7, but also goes further by empasizing the RESTful aspect which I have not yet had time to integrate.

The relation between Object Orientation, RDF and Java Beans is built into the core of BlogEd now. In BlogEd I can create an Ontology simply by anotating Java Bean like interfaces and their properties with URLs as for example in the AtomEntry interface. This gives me a simple map between the OO world and the RDF world. I can use these classes to create OWL ontologies mechanically (I will be writing the package to do this automatically next). So the emphasis on relationships, OO and universal naming is absolutely correct IMHO. If you understand Object Orientation you are one small step from understanding OWL, if you understand OWL you are one small step from being able to apply this to programming in Java.

Mark Baker points out that the relationship between REST and OO though is not so much to be found at the level of properties. That this mistake can easily be made is understandable since in RDF properties are themselves resources.

Nope, properties are properties, resources are the Beans themselves.

In my BlogEd framework this is also very easy to see. To create an object with a specific URI I can simply do the following (see MetaWeblogPublisher.getBlogScheme())

AtomScheme localHandle = (AtomScheme)factory.createObject(remoteUri,AtomScheme.class);

This returns me a Java Bean like object whose java id is the localHandle pointer and whose web id is the URI passed as first argument remoteUri. These are essentially equivalent. I can then set or get properties on that object.

What Benjamin gets right is of course that by changing the state of that JavaBean one should also be changing the state of the remote resource. By adding a new relationship one should be sending a PUT to the remote resource if not immediately then during some commit phase. During initialisation of the object one could also do a GET on the remote resource. If one wanted to create a new object one should then also send a POST to the remote server. And of coure the DELETE method is self explanatory. So at all points in this interaction the object id resource remoteUri is the key to our interaction with the remote object. It is the one that gives us the ability to change the remote state, create a remote object, deltete it, etc...

BlogEd currently does not have this RESTful integration. When I create an object BlogEd only looks at its local database to find the information. When saving state BlogEd saves it to the database but does not update a remote resource. But if we think of the database as a local cache then we may be able to think of this as a delayed update. After all REST is designed to work with caches.

The relationship between OO state and REST has become clearer to me over the last year. Up till now I have attacked the problem from an atemporal perspetive in my database. REST on the other hand is a temporal API: PUT, DELETE, GET etc, are always to be done now. In RDF this is the creation of defeasible relationships. When you change the state of an Entry you are both adding a new state in the temporal sequence of things, and changing the relationship of 'being current' from one entry state to the next. This is like changing the value of a variable in an object. The variable is, like a resource, always the same (atemporally it is always pointing at the same thing) but it's temporal states keep changing. c++! The remote handle is always the same, but its states keep changing.

So the most important aspect of RESTful programming as Benjamin points out is that now all objects are universally nameable and universally accessible. A few simple verbs allow us to create, delete and change the state of these resources. Access Control Lists allow fine tuning of responsibilities for a resource. And OWL gives us the Object Oriented conceptual structure to predict and understand the content of these resources and how they relate to others.

In summary: if the Network is the Computer, the Network + REST + OWL is a Distributed Object Oriented Database.


Post a Comment:
Comments are closed for this entry.



« July 2016