More infrastructure

What's next?

I last posted on March 11.  In that time I've had to hack my way through a thorny thicket of alternatives for another necessary piece of infrastructure  -- a RESTful server.

I've no doubt that the name sounds weird.  Fortunately there are some good articles that relieve me of the need to explain.

The first How I Explained REST to My Wife, is purposefully non-technical, and deals with some important background issues of ontologies and why they are becoming important.  The fact that that article does not actually mention ontology is unimportant. If you understand the need for defining the nouns of a project clearly and understand that an ontology is a rigorous and provable definition then you've got it.

The second, Building Web Services the REST Way, is more technical but provides more detail about the next steps forward we have to take.

Mapping the road ahead

As you will see below, a REST service layer is item #1 on a list of stuff that we still have to put into place.

Our focus up to now has been on getting a place to work, now we need to sketch out the major components of what we intend to build.

The elements I understand we will need next are :

1. A REST style service layer
2. A "maintenance" client
3. A "Web 2.0" public presentation layer
4. An ontology compatible persistence layer
5. An ontology design environment
6. An ontology "proving ground"

As of this post I have created the first four of the six.  The diagram below shows the inter-relationships between the above mentioned elements.  The parallel "technicals" blog post today The Big Picture contains detailed guides of how to create each of those elements.

MOWa Implementation Diagram Full size image

All of these are new to me, but in my reading so far I've learned some things about them:

By "layers", I refer to the need to segregate functionality by different areas of responsibility.  One thing should do one task and do it well.  Also, such groupings tend to be close to identical from one project to another and are thus easily handled generically.

1) A REST style service layer :
I've come to understand that REresentational State Transfer has a lot of advantages over the heavy connection-oriented "web applications" that were the main focus of effort for the last decade at least.  As the diagram shows, REST presents resources on the Internet with the CRUD (Create, Retrieve, Update and Delete) verbs, in the same way as in relational databases (Insert, Select, Update & Delete)

• We need to identify the best tool set for REST style projects (limited to Java, 'coz I really hate the idea of trying to learn yet another new programming language)
• We need to know how to use it.

2) A "maintenance" client :
By this I'm referring to a SPARQL client, that I can use to get straight into Resource Definition Format (RDF) storage and experiment with queries.  I know too little about this right now.  If I'm not wrong, it is analogous to the many Structured Query Language (SQL) clients like Toad, Aqua Studio and many others.

• We need to identify, and learn to use, a management tool for our permanent storage of ontological resources.

3) A "Web 2.0" public presentation layer :
I have developed many server-side applications that shove dumb HTML out to users.  Such sites just don't cut it any more.  Ajax is practically obligatory in modern web-sites because of the rich user experience it offers.  (I did an Ajax project in 1999.  Out of necessity, I invented a way of putting the smarts in the browser; a significant proportion of my user base had http crawling to them at 1200 bits per second.  I never had a chance to follow through with it, and now it has all flown past me.)

• We need to pick the optimal Ajax tool set.
• We need to know how we're going to take the raw results from the REST server and present it attractively to users.

4) An ontology compatible persistence layer :
Resource Definition Format (RDF) is a subset of Web Ontology Language (OWL).  OWL itself has many flavors, from entry level to grossly impractical research grade stuff.  Meanwhile JSON is far better suited to Web 2.0 applications.

• We need to know which is optimal.
• If we have to mix them, we need to be sure we know the best way to do it.

5) An ontology design environment :
As I understand it, Protégé is the way to go with this, and I already made a start with it three years ago (2008/05/12) and put the result on Protege_Ontology_Library.

• We need to get a very solid handle on Protégé's diagrammatic language, how it translates into OWL and how it can be made genuinely to describe the real world.

6) An ontology "proving ground" :
For this, I understand that Pellet is the tool.  My goal, misguided or not, is be able to make statements about money and money systems and prove them to be correct!  It isn't clear to me right now how I would do that with money, but consider this statement, "I'm my own Grandpa!"

Intuitively preposterous, right?  Maybe not!  Here's an ontology of family relationships, and here's Ray Stevens declaring that he is indeed his own grandfather.  If we load up Pellet with that ontology and the elements of  Ray's family, will it confirm that Ray is Ray's own grandfather?

• We need to know how to use a reasoner to prove the validity of derived "facts" deduced from raw facts in our ontological schema. 

Summary

This is still about infrastructure of course, while not forgetting the goal -- we want to provide a platform in which non-technical people can participate in exploration and experimentation with the Ontology of Money and currencies.  

This implies a loop like this :

1. Edit graphical model
2. Generate OWL
3. Make some test data implied by the new OWL version
4. Load up an RDF/OWL database with the new schema and the new data
5. Run some tests with the reasoner
6. Learn from the failures in reasoning
7. repeat from #1
   

 It takes a LOT of infrastructure to make such a loop problem free.