A Magic Hat

I have not been to many magic shows in my life so my perspective here may not be ideal.  Looking back on the few I have attended however, I do not recall ever seeing a magician pull anything out of their iconic top hat, nor even wearing said hat.  The pervasiveness of this image in popular media however assures me that the concept is not lost on society.


Consider the magicians hat.  A simple, undecorated, top hat, from which the trained user is able to pull any number of objects.  With a wave and a wink the magician is able to make materialize whatever object suits their fancy, be it a bouquet of flowers, a deck of playing cards, or the infamous bunny rabbit.  If one breaks themselves from the mundane reality of the trick, one is free to consider where these objects must have originated from.  The bunny rabbit for example surely had been hopping along a field of grass and clover prior to its arrival at the hat.  At the will of the magician it was plucked from its prior location in time and space, traveling at the speed of thought across the gap in these dimensions between the field and the hat, arriving finally in the magicians trained hand, ideally no worse for wear. 

The consumer of the trick, namely the audience, need not concern themselves with where the object appearing from the hat originated, they need only concern themselves with the fact that the objects, which certainly were not in the hat to begin with, have been made manifest in its confines and have been produced to the satisfaction of all onlookers.  


An application of this concept to the procurement of resources by an application is one of the projects keeping me occupied at the moment.  The "Magic Hat" is what I call a "Resource Container."  The principal of the container is the same as the magic hat insomuch as the user of the container is able to bring fourth from the container a resource required, not needing to concern themselves with where that resource is coming from.  The user may require a rabbit and a deck of playing cards, and while the rabbit may be pulled from a grassy field and the playing cards from a drug store shelve the users only concern is that they started off not having these two resources and they now have both of them.

A Resource Container discovers sources of resources via some discovery mechanism (the simplest of which is user configuration however more robust auto-discovery mechanisms are conceptually possible).  When a particular resource is requested of the container, if the container does not have a cached version, or if the cached version is stale, it determines, based on its known sources of resources and its knowledge of those sources, which sources to probe for information about the requested resource.  The container then produces this information in a standardized format to the satisfaction of the requester who need not know the source of the information (so long as the source is trustworthy by the users definition of trust).

To make this description more concrete, consider a resume display application.  The user may define a layout in which they want their resume to appear, indicating where they want their work history to appear, their education history, their personal information, etc.  The user may then attach this application to a Resource Container in order to acquire the actual information necessary to populate the various sections.  Imagine further an ideal online environment in which every place you have worked hosts some open API via which you are able to query your work history so long as you have proper authority to do so.  Similarly imagine that educational institutions have such a system as well.  When you request all work history tied to yourself, the Resource Container would be tasked with finding all known sources which would have resources of type "Work History" and would further be tasked with acquiring these resources.  You as a user and your front end application would not care that your work history is coming from three, four, five, etc different sources.  Using the same mechanisms to pull education history from your various schools and personal information from, perhaps, some government site, or from another service such as linkedin, the Resource Container would be able to provide to the front end application, all necessary data acquired from, ideally, the canonical sources of said data, abstracting from the front end the mundane details of the data sources.


Immediate Difficulties 


In implementing the aforementioned system I've ran into a couple immediate difficulties which I'm working through now and which are worth documenting.


Requested Resources vs Containing Resource: When requesting a particular resource, the subject of the resource being requested is often not enough information to determine where to acquire data concerning the resource.  Going back to the prior example, consider a resume application where any number of users are able to format their resumes online, connecting the front end to sources of resource information applicable to them (ie, their particular employers and educators).  If the system were requested to look up all work history data tied to a particular user, one could imagine the system being able to determine based on pre-set user configuration, which sources to look at for this information.  However, if the system were asked to pull up data for a particular work history resource, without being told much more than the URI of that resource, the system would have a hard time determining where to pull this data from.  In such an application it would quickly become impractical to ask every known employer data source whether they had information about the URI.  As such, a scheme must be arrived at to give the Resource Container more information about the particular request than just the URI.  


Performance Concerns: While I have not attempted any type of benchmarking with what's been coded thus far, I presume that performance is not going to be amazing in situations where data is needed from multiple sources at one time.  If one has a home page which is pulling data from 15 different sources, one can imagine that this may not be quick, and the speed of the population of this page will largely be dependent on the speed of the sources providing the data.  In such situations it is probably prudent to populate large portions of the page asynchronously which, while not adding much, if any, complexity to the Resource Container itself, adds to the complexity of the implementing front ends.


DnL8Tar

-PCM

On Information and Trust

Within a Semantic Web application (I supposed it does not have to be a Semantic Web application, however that's the context I have been working in and thus is most immediate to this thought) you, as a user, may be presented with and using data from multiple sources.  Since the data is all semantically linked it does not necessarily need to reside in a single store but can be obtained from another authority on the subject of the resource in question.  


A question this brought up for me was one of trust.  Trust specifically concerning the validity of the information retrieved from a data source.  Since anyone can post information about a subject given a canonical URI, the "truthfulness" of the data is questionable at best.  For instance, presuming the URI http://example.com/people/ChuckNorris was intended to reference the Chuck Norris, I could, on my website, post a tuple such as

http://example.com/people/ChuckNorris foaf:nick "Prissy Pants Magee" 

which would establish that Chuck Norris has at least one nickname and that nickname is "Prissy Pants Magee." 


Perhaps, because I was not thinking clearly, this was a concern of mine for some time.  However I eventually came to the realization that, simply moving towards a Semantic Web does not remove the onus of understanding the sources of data from the user.  As has always been the case, the consumer of information must know that the information is coming from a source that the consumer trusts.  A user trusting one newspaper and not another will be analogous to a user trusting one data source concerning Chuck Norris facts and not another.  And similarly, any tuple I may post on my website will be used only insofar as I (or my website) am (is) regarded as an authority on the subject matter.


DnL8Tar

-PCM

Concerning mod_rewrite as Related to URI Manifestation

While not a tenant of the Semantic-Web concept, certainly an ideal is the substantial manifestation of resource URI's insomuch as a web-page can be "substantial."  As defined by Semantic-Web methodologies (and RDF in general), each Resource is identified by a URI.  These URIs, being identifiers and not true locations as URLs are, are not required to point to anything substantial.  It is, however, helpful if they do, as this exposes much more robust access to the Resource.  


To exemplify this point, let us say that I have identified a particular resource, for the sake of example we'll say this resource is a single comic strip, with the uri http://example.com/comics/1.2/ns/a-funny-comic-1.  As a URI this is completely valid, regardless of whether the identifier points to anything useful when typed into a web-browser.  Let us further say that, while attributing identifiers to comics, you also set yourself to the task of creating an application housing these identified resources and exposing access to them via a webpage.  A user of the webpage is to enter the URI of the resource they wish to see and, if said resource exists within your system, it is returned to them.  Here we have a situation where the resource itself is uniquely identified by a URI and is accessible by an application.  

It would be much more convenient however if, instead of needing to know both the URI of the desired resource and the location and usage of the application via which said resource may be retrieved, the seeker of a resource could simply type the URI into a third application with which the user is readily familiar, such as a web-browser, in order to retrieve the desired resource.  In the particular example which we have been exploring this is somewhat trivial assuming you own the domain "http://example.com" (obviously, in practice, http://example.com would be replaced by a domain you do in fact own).  You could create a directory structure on your server equivalent to the URI requested and place an index file within the final child directory.  Then a request to the URI specified above would retrieve http://example.com/comics/1.2/ns/a-funny-comic-1/index.html.   


This is a reasonable starting place but the pitfalls are numerous and some not so obvious.  There is the clear downside of maintenance, be it manual or automatic.  There is also the less obvious downside of URI support.  Taking this approach forces you to use URLs as the URIs of all of your resources, limiting your naming potential.  To illustrate this, let us say that instead of the URI chosen above, you have identified your comic with the slightly different URI http://example.com/comics/1.2/ns#a-funny-comic-1.  The change is a single character but how a web-browser will handle this request is vastly different than how it would handle the previous request.  As per section 2.2 of RFC1738,

The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it.

You might be tempted to skirt around the issue by percent-encoding such characters, however this is not a viable solution either since, per section 2.2 of RFC398 (coincidence that these notes are both from section 2.2 of their respective documents?), "#" is a reserved general delimiter and, 

URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent.

Given this let us return to a previous portion of the example.  What would be ideal is if you could leverage the URIs full scope of delimiters, and instead of the URI typed into the web-browser being treated as a URL, it was passed to a subsequent application which would properly treat it as a URI and return to the user the identified resource.

mod_rewrite

mod_rewrite is an Apache module which allows you to rewrite a requested URL based on a series of conditions and rules.  The rewriting happens on the sever side so the user is not made aware of the change in request (that is to say, the address which the user has entered into the address bar does not change).  This module gives us the ability to "catch" a requested URI before it is fully processed as a URL and rewrite the request into something the server will actually be able to process as the user expects.  mod_rewrite may be implemented at either the server or directory level and while it is always best to implement such modules at the server level, there are cases where it is more appropriate (or necessary in the case of a shared server) to implement the module at a directory level via a .htaccess file.

Returning again to our example, we might write rewrite rules stating "any time a user makes a request to an address starting with http://example.com/1.2, hand that request to our resource retrieval application (introduced earlier in this post) passing the fully requested URI as a GET parameter."  Such a rule might look like this (assuming implementation at the directory level starting at the root directory of example.com):

RewriteEngine on

RewriteRule ^comics/1.2/(.*) request-resource.php?uri=http://example.com/comics/1.2/ns/$1 [L]

Breaking this down, the RewriteRule first specifies the condition under which the rule should fire.  This condition is presented as a PERL regular expression.  The regular expression presented in this example states that this rule will fire whenever it encounters a request "starting with comics/1.2/ and followed by any number of characters.  The RewriteRule then specifies the action which should be taken when the rule is fired.  In this case, the request is rewritten as a request to the code "request-resource.php" and the requested URI is passed as a GET parameter (the $1 within the URI indicates the remaining portion of the request which was denoted by "(.*)" in the first portion of the RewriteRule).  Finally a set of optional flags may be presented to the RewriteRule.  In this example we present [L] meaning that this is the last rule which should fire.

Given this code (and the assumption that the previously discussed application is in-fact accessible via the php file request-resource.php) users may now enter URIs for resources defined within the http://example.com/comic/1.2/ns/ namespace simply by entering the URI into a web browser.  

Note: this technique will not handle all URIs, for example, "urn:oasis:names:specification:docbook:dtd:xml:4.1.2" would not be accessible via this methodology though it still stands as a valid URI.

DnL8Tar

-PCM

On Imagination and Experience

I posit the following query as a mental exercise.

Consider, if you will, a person, completely blind from birth, never having seen light of any type, knowing only sightlessness.  If asked, how would you describe color to this person?

I will reserve my own answer for it is irrelevant to the point overall however consider yours.  Indeed it would be a difficult task, but why?  Color is a concept familiar to us.  We see color every day and use color to differentiate one thing from another, or one type from another.  Further we can know of colors, their form, absent of their application to matter.  Color may be used in describing a thing known, or in conceiving a thing to be known.  Why then should so familiar a thing be so difficult to portray.

The answer lies in the blind persons lack of experience of color, or of sight at all.  Indeed color is perceived through the sense of sight and we only have experience of color through this sense.  The blind person however has no experience with this sense, no basis on which to know color.  And try as we may, we can only convey an abstraction of color, but can not impart a knowledge of color itself.

Our knowledge is built of our collective experiences, our perception of those experiences, and our rumination thereof.  We can give to our self more knowledge, or deeper knowledge, by building upon that gained by our experience, but we can not give our self knowledge without experience.  That is to say, we can not give our self knowledge from nothing.

What then is left to say of imagination?  For we do certainly contrive those things which do not exist and know them in or mind, and can give to others information about them so that they may know them as well.  But these things which are the objects of our imagination are not brought out of nothing, but are also brought of our own experience.  As an example, consider a dragon, a creature which, in this world, does not exist, but is brought forth from our imagination and made manifest to others.  Even this creature however is not brought fourth from nothing and we can consider its components and their familiarity to our experience (skin like a reptile, facial structure like a horse, wings like a bird, etc).  The objects of our imagination, however far they are from reality, are never so far that they do not extend from our experience.


DnL8Tar

-PCM

On Knowledge and Information

http://informationr.net/ir/8-1/paper144.html


A decent paper focusing on the misuse (and overall meaninglessness) of the phrase "Knowledge Management."  This has given me reason for pause in my own use of the phrase and after some consideration I believe it may be best to cease using the phrase altogether.  


In the interest of definition
Knowledge is that which is known to an individual as gained by the individuals experience and as colored by the individuals perception.  Any attempt to "transfer Knowledge" from one individual to another (as the phrase is used popularly) entails first the transformation of Knowledge into Information via some medium (ie, writing, speaking, etc) and second the consumption of the Information and its interpretation resulting in Knowledge.  It is important to note here however that the Knowledge transferred into Information is not and can not be the same Knowledge known to the consumer of the Information.  It can be similar, and certainly if the Information is clear and the consumer is up to the task of consumption, it will be, but as it is imputed to the individual it will not be the same in two individuals.


DnL8Tar

-PCM

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