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

Powered By [enter name here]

I have been a long time advocate of home-brewing (code, not beer... unless you know what you're doing, thought I suppose the same could be said for both).  I refused, perhaps from a desire to learn, or perhaps sheer arrogance, to use packages which were not included in a programming languages core.  For me, to download a library, which someone else had written, and use it in my own code was closer to blasphemy than my sensibilities would let me tread.  In retrospect the distinction between those things distributed with a language via it's core and that which one would need to download seems paltry, though my adherence to a rejection of the later has led to some interesting thoughts on levels of knowledge.

Once, I heard it said, "You do not need to know how to build a car in order to drive a car."  Statistically this is sound simply based on the observable myriad of car-drivers in comparison to the relatively few auto-repair workers.  The statement may also be applied to domains outside the realm of automotive engineering.  For our purposes, we will apply it to programming.  My prior personal decision to set-aside external packages and, by inference, frameworks, forced me to learn how to build these packages and frameworks.  However, there was a limit to the depths to which I was willing to delve.  I did not, for instance, write my own programming language before using PHP.  Similarly I did not write an operating system before turning on my computer.  Essentially, the distinction between functionality provided by a languages core distribution and add-on functionality established the domain, or level, of knowledge I was endeavoring to internalize through work on my personal and academic projects. 

Often I've said (sometimes to others but usually to myself) that a serious Computer Scientist should not use a built package or framework without having make a comparable package themselves.  The statement is too broad however and does not accurately reflect the concept of knowledge levels.  It would be better stated in the context of a particular domain, such as "someone who is serious about learning how content management systems work should not heavily use a content management system without building their own."  Similarly, one could say "someone who is serious about understanding how a programming language works should write their own programming language."  Creating such a system may seem a waste of time in so much as the system will more than likely be tossed aside at a later point in favor of a more robust and mature system of the same genre.  The experience however is edifying.

One should explore ones purpose before setting forth on an endeavor of this ilk.  Are you attempting to truly understand how a system, or genre of systems, works, or are you attempting to setup something that functions as expected without any grandiose visions of future changes outside the bounds of what a particular framework provides?  If your purpose is the latter, home-brewing is admittedly overkill and, assuming a first attempt at brewing said genre of system, would result in an application of questionable stability.

This line of thinking was largely inspired by my explorations in JQuery, a Java Script library which I have given a wide berth until recently.  While elegant, understanding of the library, and usage thereof, is not trivial, barring a willingness to code on blind faith and the kindness of support forum members.  Statements like "functions are first class citizens," with which the JQuery documentation is rife, hold little weight to someone who has not coded a Javascript closure.  

Thoughts?  

DnL8Tar

-PCM

TTT Discourse

Rules of a Tic Tac Toe universe

1. A statement is valid if it is made in order [rule 2] and if the square of the board indicated by the statement is un-owned [rule 3].
2. A statement made by a player is considered "in order" if the prior valid statement was made by the opposite player or if the player is player 1 and their statement is the first of the game.
3. When a player makes a valid statement, ownership of the square on the board coinciding with the statement is given to the player.
4. If a player owns three squares all in the same row, column, or diagonal of the board, that player has "won" the current game. The opposite player has "lost".
5. If all squares of the board are owned and neither player has won, the game is drawn. Neither player wins and neither player looses.
6. Once a winner is established or the game is drawn, ownership of all squares on the board is revoked returning each square to a neutral state. This starts a new game or iteration/generation of the universe.

I submit for consideration a reflection on an abstraction of the game of Tic-Tac-Toe.  This abstraction considers the moves of a tic-tac-toe game as a universe of discourse.  The rules of tic-tac-toe are, along the same line, the rules of the universe, governing the reaction of the universe to each "statement" made.

Three distinct entities make up the universe: two players and a board upon which the players interact.  The players I will refer to as player 1 and player 2 when differentiation is necessary.  The board is, to those who are familiar with the game, a standard tic-tac-toe board, consisting of 9 squares laid out in a 3x3 grid.  Players are the only acting entities.  Their interaction is performed via the board using the vocabulary set forth by the universe.  For purposes of the abstraction the specific semantics of the vocabulary are inconsequential so long as a player can formulate any valid tic-tac-toe move via use of the vocabulary.  The following set is one such vocabulary: { (-1,1), (0,1), (1,1), (-1,0), (0,0), (1,0), (-1,-1), (0,-1), (1,-1) } where each element in the set represents a square on the board.  Using a standard Cartesian coordinate system, the element (-1,-1) represents a move to the bottom left square and similarly the element (1,1) represents a move to the top right square.

At any point a player may make a statement by selecting a single element from the vocabulary.  The universe then responds to the statement.  As noted the players may make any statement at any time.  The notion of "turn" or "valid move" is not instilled in the player but in the rules of the universe.  This being the case it is possible for the players to make statements which do not change the state of the board based on the rules of the universe.  For instance, assume player 1 makes the statement (1,1) and player 2 subsequently makes the same statement.  The second statement is, in a sense, rejected by the universe as the state of the board is not changed by the statement. 

Such statements I will call meaningless.  Thus the meaningfulness of a statement is determined by whether the statement results in a change of the state of the board.  If it does, then the statement is considered meaningful, otherwise it is considered meaningless.  Of course, the rules of the universe determine whether a given statement changes the state of the board.

Given this abstraction one can conceive of a learning algorithm applied to the players such that the players learn from each statement made.  In order to learn the players must be directed toward some goal.  If they are not then the algorithm has no bearing with which to process each move.  One obvious goal of the game would be to win.  A similar and secondary goal would be to not lose.  A third rule of some usefulness would be to make only meaningful statements.

Given these goals, coupled with well defined rules over the universe, the players could conceivably "learn" the rules of tic-tac-toe based on their observations  of the reactions of the universe to their statements and the other player's statements.  Further, the players may develop stratagem coinciding with their goals of winning and not loosing (though this later item is of lesser interest to me at the moment).


DnL8Tar

-PCM

Resource Driven Development - A Definition

As a thirty second Google (Topeka) search for the phrase "Resource Driven Development" did not turn up anything relevant to my purpose, and as I never allocate much more than thirty seconds to a Google search, I am going on blog-record with what I would define the phrase to mean.

Resource Driven Development refers to development done within a framework where the behavior of a system is based on resources defined within a system-specific ontology.  

This model of development is precisely what my framework hopes to deliver, abstracting presentation logic into resources and data population logic into the ontology.

DnL8Tar

-PCM

Rolee Polee

I purchased the "Rolee Polee" on October 27, 2009.  My intention in its procurement was to reduce movement between my keyboard and my mouse which are approximately one and one half feet apart.

One uses the Rolee Polee by holding it, as portraid in the thrid image to the right,  by placing ones index finger through the hole in the device and using ones thumb on the small trackball and two mouse buttons on top.

In principal this device is quite useful, allowing one a higher freedom of movement during mouse usage.  Even assuming proper functioning of the device itself, the Rolee Polee is not ideal for users who are switching between the keyboard and the mouse regularly.  To make use of the Rolee Polee, as previously described, the user must palce their index finger into a hole in the Rolee Polee.  When switching back to typing, the user must take the Rolee Polee off of their finger.  Thus, the time saved in not having to move ones hand to and from the mouse is lost and then some in the picking up and putting on of the Rolee Polee.

This flaw aside, the device in and of itself is defective.  The buttons on the device are fully functional.  There are two one the top, one representing the right mouse button and one representing an augmentation of clicking on the scroll wheel of the mouse.  Also, there is a "trigger" button located across the natural position of the users index finger which represents the left mouse button.  The track ball is the portion of the Rolee Polee which is highly defective.  It consists of a small, hard plastic, green ball running over a series of small rollers meant to track its motion.  This small hard plastic track ball is not large enough to fill the cavety carved out for it and thus does not have ample cohesion with the rollers.  Strangely the device works for a few minutes out of the box, however shortly there after movement of the mouse is largely limited to the horizontal plane.  Many online reviews of the product report similar problems with the device leading me to believe that I did not receive a lone defective unit. 

In fairness, for the short period of time during which the Rolee Polee was working, it was very comfortable to use and the positioning of the buttons and track ball felt natural and did not require any acclamation. 

In Summation

I would not suggest this purchace . Given the devices track record of being defective it is not worth the risk.  If you can find a higher quality track ball which would fill the cavety provided it may be a higher functioning tool, but as is, it is nearly useless after a day. 

Had I found their website prior to purchase I may have thought twice as well. 

DnL8Tar

-PCM

To "Keep Pace"

In formalizing the problem at hand, as was done in my Dec 10 post, I have remained wholly objective in definition of the problem itself and have avoided the temptation of attributing any of its parts to a given implementation. The terms used in the description of the problem however remain subject to the translation of the reader.  "Keeping pace" is such a phrase which lends itself well to a range of interpretation and thus begs definition.

A View of the Semantic Web must be capable of keeping pace with the Semantic web itself. 

Usage of the phase in this context is intended to denote a level of conformity between the pace keeper and the pace setter.  Movement in the Ontology is to be made manifest in the View.  In accord with the final passage of the problem, "without recourse to re-implementation upon a change in the ontology," it can be stated further that movement in the Ontology must be made manifest in the View without direct modification to the View itself.   

It follows that the View must be informed of changes in the Ontology.  Absent this any manifestation of change in the View would be guesswork akin to the man who dresses to step out on a Spring day without first checking the weather.  Thus between the View and the Ontology must reside a third entity aptly named the Crier who sings loudly to the View of the works upon the Ontology such that the View might conform itself to the authority of the Ontology.  

Here we walk on precarious grounds for as the resources of which the Model is made up are of the Ontology are we not mingling the View and the Model which are to remain distinct?  I argue in the negative, my reason being that the Ontology is an entity separate from the Model.  Consider the definition of the Model briefly set forth in my prior post.  The Model is that in which resides the "business logic" of the system.  We stipulate that as applied to the Semantic Web the resources and operations upon them are the matter of which the Model is made.  

The Ontology, in relation to resources, is the definition of the nature of the resources.  Should we then say that the nature of the elements of the Model is part of the Model?  This is perhaps more an object of philosophy and may be best to be left as such.  Can one say that the nature of those things which are apples is contained within a particular apple?  Certainly the individual apple exhibits those characteristics set forth by its nature, but we can not define one apple from another without recourse to the nature.  Therefore in the same way that one does not say the nature of the apple is of the apple, or of the totality of all apples for that matter, neither does one say that the Ontology is of the Model. 

DnL8Tar

-PCM