I did a short presentation (3 slides) about requirements for a new subject-centric programming language on TMRA 2007. I made a reference to COBOL as a language that had built-in high-level support for defining and manipulating “business data”. Many modern programming languages “outsourced” data handling to relational databases and lost transparency and simplicity in manipulation of data.

Object-oriented programming languages (starting with Simula ) help to model various “things” in our computers. But object-oriented languages are not optimized for representing our knowledge about these “things”. For example, it is quite easy to define a class that represents people with several properties such as ‘first_name’ and ‘last_name’ (Ruby notation):

	class Person
	   attr_accessor :first_name,:last_name
	end

It is easy to create a new instance and assign some values:

	p=Person.new
	p.first_name='John'
	p.last_name='Smith'

But what if we need to represent a situation when names can be changed over time? What if different sources have different information about names of the same person? What if information about names is not available directly but can be inferred/calculated based on exiting data and various inference rules? How can we specify that some object properties can be viewed/modified only by specific user groups?

What if we need to persist information about an object in some data store and retrieve this information later? What if we need to access and modify this information on a laptop when we do not have connectivity. How can we synchronize this information with a desktop that is connected to the network all the time?

These “basic”, everyday requirements break easily simplicity of traditional interpretation of the object-oriented paradigm and introduce complicated “frameworks” and APIs. Instead of using objects to model “things” we need a lot of objects do deal with infrastructure and to model technical aspects of our knowledge about “things”.

Dynamic languages such as Lisp, Prolog, Python, Ruby etc. allow to “hide” technicalities using meta-programming. These languages allow to build required “technical” constructs behind the scenes and help programmers to work with domain level objects.

For example, we can use “metaproperties” to define domain specific associations, names, occurrences and types:

	class KnowsPerson < ActiveTopic::Association
	    psi           'http://psi.ontopedia.net/knows_person'
	    historical    true
	    symmetrical   true

	    role :person, :player_type  => :person, 
	                  :as_property => :knows_person, 
	                  :card_min => 2,
	                  :card_max => 2
	end

	class FirstName < ActiveTopic::Name
	    psi          'http://psi.ontopedia.net/first_name'
	    historical   true
	    card_max     1
	    domain       :person
	end

	class LastName < ActiveTopic::Name
	    psi          'http://psi.ontopedia.net/last_name'
	    historical   true
	    card_max     1
	    domain       :person
	end

	class DateOfBirth < ActiveTopic::Occurrence
	    psi          'http://psi.ontopedia.net/date_of_birth'
	    domain       :person
	    card_max     1
	    data_type    :date
	end

	class Person <  ActiveTopic::Topic
	  psi          'http://psi.ontopedia.net/Person'
	  sub_type     :thing 
	  name         :first_name
	  name         :last_name
	  occurrence   :date_of_birth
	  association  :knows_person
	end

We can use defined constructs to manipulate domain specific objects:

	a=Person.create(:psi=>'JohnSmith',:at_date => '2007-10-01')
	a.first_name='John'
	a.last_name='Smith'
	a.save

	b=Person.create(:psi=>'JoeSmith',
                                  :first_name=>'Joe',
                                  :last_name=>'Smith',
                                  :at_date => '2007-10-02')
	b.save
	a=Person.find(:psi=>'JohnSmith',:at_date => '2007-10-03')
	b=Person.find(:psi=>'JoeSmith',:at_date => '2007-10-03')
	b.knows_person << a
	a.save
	b.save

Ruby and other dynamic languages allow us to go quite far in defining domain specific languages. But if we look at CTM, TMQL and TMCL, we can think about even more advanced programming language that natively supports various assertion contexts (time, source, etc.), metadata, information provenance and various inference/calculation mechanisms.

Links:

- Larsblog: TMRA 2007, day 1

- Larsblog: TMRA 2007, day 2

Short presentation on TMRA 2007, COBOL and Topic Maps?