A Brief Consideration of Continuity and it's Implications on Computing

Consider a computer, stripped of its layers of abstraction which expose to users access to its facilities.  At the core of a computer is a binary processor acting on logical operations.  Each such operation is executed at a set increment, controlled by the computers clock speed.  These small operations are combined together through layers of abstraction to produce the robust functionality we have come to expect from a machine such as this.  

On such a system one with proper knowledge could produce an animation of, let's say, a ball rolling across a table.  During the animation the ball traverses the table, rolling from a point we shall call a to a second point which we shall call b.  Once produced the user can watch a playback of the animation and, assuming it was well produced, would not be surprised to see what they would naturally expect to see if a ball were indeed rolling across a table.

Further, consider a true ball in the physical world rolling across a true table from the same point a to the same point b.  Along the path between these points, as many points as you please may be observed  as well, and never can we observe so many points in between that there are not more which can be observed.  This continuity of movement, and of being, is innate to objects in the natural world.  The ball from our example moves continuously along the path from a to b, through the infinity of measurable (measurable either arithmetically or geometrically) points over an amount of time also exhibiting continuity.

In comparison, the animation which is produced consists of a series of frames displayed at a set rate.  Each frame can be said to be a measurement of the position of our virtual ball at a specific point in time.  From this animation select two adjacent frames.  In between these frames could be inserted a third showing the position of the ball at a point in time half way between the point represented in the first frame and the point represented in the  second frame.  Again, selecting this new frame and it's adjacent frame, another new frame could be made to show the point in time representative of the mid point of these two frames.  Such a process could be repeated as many times as we please without reaching a final result.

This is representative of a large limitation of a binary representation of continuity.  While binary operations are able to perform logical processes with accuracy, the representation of continuity is limited to an approximation.  The producer of our ball and table animation is forced to select points in time which will be shown on the frames of the animation and then calculate where the ball would be at that point in time.  While such an approximation is more than suitable for the domain of animation (as the eye can be tricked into seeing continuity) it is less desirable for a true simulation where the interaction of events across a continuous flow of time is to be observed as opposed to the state of events at a discreet point in time.

DnL8Tar

-PCM

RDF as a Database Solution

With "linked data" taking a front seat in my research efforts over the last few years, my use of RDF has increased in state from "I have no idea what RDF is" to "RDF is the backbone of my system architecture."  I have a tenancy to go over board with such things, especially when learning a new technology or technique.  Case and point, Recursive-Living.  The JavaScript framework I created and build Recursive-Living on top of was made solely to deepen my knowledge of AJAX style programming and it's various pit falls.  This being the case, the entire site is delivered via AJAX and JavaScript.  While this is admittedly overkill, such a rigorous approach to the development of conceptual knowledge yielded many fruits, most detailing why such an architecture is ineffectual in practice. 


Two web applications which I have spoken of before, if not in this forum then in Buzz, Transaction-Tracker and Comic-Post, I have built wholly on an RDF backend, again, for the sake of deepening my knowledge of RDF, RDFa, and OWL.  The intention for both of these applications was, in part, the study and extrapolation of the needs of a suitable framework upon which such applications could be build, the very same framework of which I have spoken previously.  Delving deeper into this intention is fodder for a future post which I might write.  During development of the aforementioned applications I have compiled a good deal of information around the conceptual use of such systems.


There are many distinct advantages to using an RDF database, or an RDF abstraction over a database schema, as a data store.  These advantages are considered in comparison to more traditional data store architectures, where tables are designed around the data and relationships between the tables are conceptualized on smooth white boards spanning long walls in stark rooms.  I list below the advantages which I have formalized to date.

• The tables with which the developer need be concerned are limited to the RDF implementation.  If new types of data are added to an existing application or if existing types of data are augmented or altered in any way, the tables themselves need not change, only the data on the tables.
• Relationships between resources are concretely defined.  This is as opposed to the more abstract definition of relationships between tables which often occurs based on key columns.  Resources relationships are defined by linking their URI's together via a property or attribute.  Since these definitions are concrete they can be easily traversed without the need for explicit codification of each relationship.  Such an implementation allows for processes such as a recursive resource lookup, where a resource, and all it's related resources, and all resources related to those resources, etc, are found, built, and returned to the user.
• RDFa output is made trivial if your backend is already in RDF.  While not particularly important at the moment, with more web applications being built around this concept, it will soon become crucial in promoting a site and helping automated agents find and navigate said site.
• Type checking and existential validation is simplified in this model since each URI is a resource in your data store.  If using RDF in conjunction with RDFS (and OWL, though OWL is not immediately necessary for this purpose), the type of a URI (or class of a URI) can be quickly verified via a SPARQL ASK query.  Again, since the application need only trouble itself with one set of tables, only one such ASK query need be defined.  In comparison, one would need to define a query for each table in a classic data store infrastructure in order to see if a particularly keyed row existed.

Certainly there are disadvantages as well and a topic for future consideration which I have not begun to tread upon is performance comparisons.  These again, I leave as fodder for a future post.  


DnL8Tar

-PCM