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.

Structuring the work.

 Last time was my first post of my first blog, and already I see I made two mistakes

1. I should probably add, ojalá (or Insha'Allah which is surely where it comes from) if ever I say "...that's for tomorrow"
2. Seems Jena is not the back-end.

For a while yet I still won't be able to give top priority attention to this blog due to a not-yet-closed contract.

As regards the role of Jena :

"The primary use of Jena is to help you write Java code that handles RDF and OWL documents and descriptions."  Ian Dickinson -- http://www.iandickinson.me.uk/articles/jena-eclipse-helloworld/

Well, you will see I'm pretty far along with that, but I can see I still have much to learn.


I've realized that the best way to structure this work is in three separate blogs, since the material here is going to be interesting to three probably unrelated groups.

This main one, Monetary Ontology Walkabout, will be brief; most of it will point to new items in the other two. It'll be for those who want to follow progress and jump in when I get to something that's important to them.

The second, Monetary Ontology Walkabout - Technicals will be very geeky, but I'll avoid too many buzzwords, and provide lots of tutorials as well as all the source code.  The idea is to offer something people can really use, so I mean to make it easily accessible.

Finally, Monetary Ontology Walkabout - Ontology Stuff, doesn't really exist yet.  This will be for money geeks -- those who want to actually work with monetary solutions but may prefer to have someone else deal with the Information Technology details.  It will tend heavily toward the ontology of money

Most of the work, for now, will be in the Technicals blog, since we are building the foundations on which the rest will reside.

Indeed, I just now posted a detailed setup guide there, with links to a series of tutorials, as Wiki pages, hosted on a wonderful service I've used for over two years with complete success, www.xp-dev.com

Please visit the main Wiki page, and the source code page.


Next steps?

We got to this point 'coz of all the RDF stuff in the Jena tutorial :
%JENAROOT%\doc\tutorial\index.html which leads to this kick-off course :
%JENAROOT%\doc\tutorial\RDF_API\index.html

Apparently, I've done things a bit out of order. The Jena tutorials seem to push you to understand "A Semantic Web Framework" (which is their subtitle of course).  That isn't exactly what I want to do!  I'm more interested in the overall architecture.  I guess I need a map of the whole territory before getting to know the land around a single water hole.

In the next post we'll try get a map of the whole territory.

Hello World

Hi!  Thank you for coming to visit.

Over coming months I hope to create an ontology of money able to achieve wide spread acceptance.

It will build upon a very crude attempt I made three years ago, very kindly linked to (https://financialcryptography.com/mt/archives/001047.html) by Ian Grigg in his superb blog "Financial Cryptography".  I put it together as an in-at-the-deep-end leap into Protégé (http://protege.stanford.edu/).


That version doesn't have much more value than to act as an intro for interested parties, as in, "There, that's what I'm talking about."

So ... that diagram lets you see what I am talking about, but probably leaves you wondering what the point is, so here's a bit of a Q & A session:

Q: Monetary Ontology. Fine  ...  and Walkabout?

A: A diagram is nearly useless.  Much more is required.  I want something people can use.  For that to happen, an ontology needs to be tested and proven correct.  That involves transforming the ontology into a database structure definition (schema), preparing a database with that schema, loading up it with real world data and then testing that a reasoning engine will always answer queries with realistic results.  This is all new territory for me, so like a pubescent aborigine, I now set out Walkabout to make the vision a reality.  I have the songlines in my head.  I invite you to watch my progress.

Q: What's the point?

A:There are as many definitions of money as there are economists.  Economics poses as a science, but if there exists so much ambiguity about what money is then how scientific, really, is the rest of economics?  Economists have the fine luxury of having authority without responsibility!  ... and what an unholy mess they have made!  This initiative grows out of the conviction that money based on solid foundations is not at all hard to understand; a mumbo-jumbo priesthood is only required when a fraud is tarted up as arcane mystery.


The point is to make it clear what money is, and make it possible to prove the definition by testing it.  The language with which one defines a ontology is extremely limited, only certain kinds of things can be said.  I have dropped out of many discussions about money because the language used was so loose and contradictory that agreement on anything was impossible.  The benefit of a constrained and rigorous language intended to facilitate describing the real world ought to make agreement on many things quite possible.

Q: What's the route?

A: Well from past experience in other areas I think it is wise to work from the back-end to the front-end.  That is to say make sure I know how to :

1. prepare a simple database schema
2. load some data into the database
3. connect to the database from an application
4. see that query results can be validated through a reasoner and properly reflect the real world
5. augment the simple database schema by transforming an augmented diagram
6. repeat 2, 3 & 4

---

So my first task is step #1.  


Having spent a few hours poking around, it seems that Jena is a suitable candidate for a back-end.


I downloaded the latest version from sourceforge ( http://jena.sourceforge.net/downloads.html ) and found the first tutorial here at %install_path%/doc/tutorial/RDF_API/index.html.

So that's for tomorrow....