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

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

Starting at the Beginning

As a principal, when one takes to the task of solving a problem, it is of indispensable value to have ascertained a full grasp of that which is to be solved. He who endeavors upon such a problem lacking this will surely find a solution to nothing more than the problem of excess time. It is exactly this problem which I have lamentably solved time and time again for lack of the aforementioned principal.

I believe it was St. Thomas Aquinas who once observed "an error in the beginning is an error indeed." So as to dodge such folly as can be avoided I will be at some pains herein to set forth the problem, or problems as the case may be, which the intended system is meant to solve.

We start with the definition of a model which, in a sense, can be said to be the impetus for the problem itself, the Semantic Web. The notion and movement of the Semantic Web, as defined by those who define such things, is aimed at the bringing about of an interconnected web of data points, the connections between which are made meaningful by use of a common ontology. Work in this area is therefore performed in the space of resources and is concerned heavily with their creation, modification, destruction, and, most importantly, relation and aggregation. There are and have recently been made advances in systems for handling such operations. Many of these systems are satisfactory and some are quite mature. Thus it is not in this realm that I wish to focus my attention (though hitherto it has been this area to which my efforts have been employed).

As is, the Semantic Web would be a great boon for machines duly coded to handle the interpretation and aggregation of such information as the web can provide. Creating a meaningful view of the information is another beast entirely. Consider the Model-View-Control paradigm, pervasive in the domain of computer applications. This pattern mandates a strict decoupling of a Model and a View. Traditionally the Model is defined as that part of a system or application in which resides the "Business Logic" of the system or application. More often than not the data which the application uses, if any, is presented as part of the Model, though additional design patterns may endeavor to abstract it otherwise. The View then is that thing which is used to display that which is in the Model in such a way as is appropriate for the intention of the application. Applying this notion to the Semantic Web results in the resources of the Semantic Web being cast to the domain of the Model. The View then, highly variable based on the intended application, is that which presents resources to the intended consumer.

Some brief meditation is needed in order to see the consequence of this and the burden undoubtedly put upon the unfortunate fellow of whom a View is asked. It is easy enough to conceive of a relatively straight forward system designed for the purpose of viewing a single resource at a time. It is almost equally easy to do the same for a system providing a mapped view of the resources and their connections. Additional, and dare I say more realistic, requirements may place further restrictions on the View however. While I am not in a position to postulate a fully enumerated list of such requirements one can surmise that it may be of value to only show certain types of relationships. One may also surmise that, as we are considering a View, the consumer of said View may require a specific layout to be adhered to or multiple layouts depending on the type of resource presented.  Such an implementation is cumbersome even once and the dynamic nature of the Semantic Web increases the burden on the developer of the View as they will most certainly be required to make constant updates to the view in keeping with the ever changing, ever growing, ontology space of the Semantic Web.

And thus we come to the very heart of the matter. Problem: A View of the Semantic Web must be capable of keeping pace with the Semantic web itself.  Such a View must also allow for conformity to requirements concerning resource View positioning, layout, and associated resource requests, without recourse to re-implementation upon a change in the ontology.

~~

My efforts to be succinct in exposition have clearly failed.  However, with problem stated progress can be made towards a solution with clarity.

DnL8Tar

-PCM