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?