Dynamic Expressiveness
Structured data is not dynamically expressive and so are not our applications and digital communications. For example, if a contact in our address book has a phone number that is now obsolete, it would be nice to keep that number, mark it as obsolete, maybe add an obsolesce date and a comment “Mike lost his phone” before adding a new phone number. Or, if we send an order to a web shop, it might be necessary to add a condition to an item “only if item x has feature y”. You can do this if you use a paper address book or if you send a fax to the shop. However, there is no way you can do that digitally if the developer of the contact app or web shop has not provided that feature.
In some way, we have lost a lot of expressive freedom since we started managing all our tasks using computers. We are completely dependent on software features, doing anything outside that feature-box is impossible. In case of the address book, it is an inconvenience. In case of the purchase order, it might cost us time and money to return that delivery. When we communicate with our employers or even governments digitally, it might be crucial to be able to express ourselves freely.
Havel is a very expressive language. Values can be indirected and then annotated, qualified, dated, decorated or contextualized. Instances can be extended, models can be customized.
Figure 1: A simple Havel expression defining a human named Peter Pan.
Figure 2: Semantically identical expression, the name property has been indirected and annotated, which does not change the meaning of the expression.
Many of these features (language concepts) are universal, they can be applied to any value in any place and can be nested as well as chained. This universality enables many advanced language constructs that allow Havel to be maximally expressive.
Many of these features can be used on data without changing their semantics. Extending an instance or annotating a property value does not necessarily change the meaning of an information. An application or functional module should be able to understand and process the modified information; at least as long as it is within the scope of configured modelling rules.
Figure 3: Semantically identical expression as figure 1 and 2, the name property is now dependent on language context and the textual representations have been annotated with comments
The two examples above would have been very easy to achieve in Havel; annotating and extending information is a fundamental feature. Havel is designed to make digital information a bit more humane, to allow us to express ourselves precisely or vaguely, whichever version fits better.
This post is part of a comprehensive introduction into SRDM, graph languages and Havel.
Continue reading: Interpretable Information
Comments