Do Objects Have Souls?

While writing the article, Implementing "Real" Classes in JavaScript for Developer.com, I was tempted to add a sidebar with the provocative title "Do Objects Have Souls?".  The article itself demonstrated a technique for simulating Java-like classes in JavaScript, and as introductory material, it explained the difference between Java's "class"-based semantics versus JavaScript's "object prototype"-based semantics.

For Java programmers: In a nutshell, Java creates object instances that have all, and only, the properties of its Class, and the property list is fixed over the life of the object. In JavaScript, object instances have no "real" class, however, each object is free to add and delete properties at any time.  Because of this, JavaScript Object objects are pretty empty compared to Java Object objects at birth because they can become anything after they have already been instantiated [hence Existential Programming!].

In trying to understand the language differences myself, I began musing on the parallels between philosophical notions of "the soul" and JavaScript's empty shell of an "object" that is generated by obj = new Object;

Souls as property containers

In western philosophy there has been a 2500 year old school of thought that "things" (aka objects) have properties, some of which can never change (i.e. essential properties) versus those which may change over time (i.e. accidental properties).  One concept of "soul" is that it is the bundle of essential properties that constitute a thing.  This idea has also been equated with "identity".  Attached (non-permanently) to the attribute bundle are the various accidental properties.  This sounds a lot like the "empty" JavaScript object which is ready to add and update and delete [accidental] properties, while all the time keeping constant the essential, unchanging, object identity (as referenced by obj !).

When medieval alchemists distilled liquids into their essences they called them spirits because they were the "soul" of the grape, herb, flower, etc. To insure removing all of the accidental properties, they distilled things 5 times to produce the quintessential spirit.  Distilled spirits in the alcohol sense often have names that reflect the notion that they have a life essence captured in them. Whiskey and Aquavit are both names that translate into "water of life" in their original languages.  In the movie Perfume, a villain repeatedly attempts to distill the essence of pretty women using the same techniques as distilling flowers into perfume. [Spoiler Alert: flowers don't survive the process...]

When the Well of Souls runs out of RAM

Another aspect of souls that rhymes with JavaScript is the ancient lore that newborns are given a soul at birth which is plucked from a "well of souls" (aka the chamber of Guf).  In JavaScript, as empty objects are created and given an identity, they are plucked from a heap of available memory (i.e. dynamic memory allocation). In both cases, bad things happen when there are none left.

When the well of souls runs dry, the Messiah will come and reboot the world; when your browser runs out of heap space, your JavaScript will gag and someone will have to come and reboot the browser (or at least the web page).  The plot of the 1988 Demi Moore film, The Seventh Sign, is based on the Guf mythology. Demi's baby is due to be born on February 29 which is the date on which the last soul will leave the Guf and it will be empty.

XistP is the abbreviation for Existential Programming

After having written many blog posts, essays, emails, etc, etc using the phrase "Existential Programming", it is getting pretty tedious to keep spelling it out.  An official abbreviation is needed!

Unfortunately for me, XP is already taken for "Extreme Programming".  XSP is taken TWICE!
Once by Apache for eXtensible Server Pages, and also for an ASP.Net server implementation. XIST is the name of an RNA gene, XSTP is the eXtended Satellite Transport Protocol, xISP/XISP/Xisp is used for all sorts of things, ...

...so, the not so short (but shorter than the whole phrase) XistP is my choice for the official abbreviation for Existential Programming.

Is there anything left after all the roles are stripped away?

While reading Looking at Philosophy[1], I came across its discussion of Kierkegaard saying that there is some existential being that is left when all the "roles" of that being are stripped away.  With my advocation in Existential Programming that "roles" be promoted over "is-a subclassing", it begs a deep question. If we have factored out all state and behavior from a class, moving them into various roles, when do we know that it is time to create a new instance of a "thing" to which roles will be attached?

For example, in a language like Javascript, one can create an empty object instance and dynamically add in attributes and methods later.  This capability can be used to implement "mixin" classes that each encapsulate the properties and behavior associated with some role.

While it is true that we can program the operations of instantiating an empty (i.e. essence-less) object and graft in the mixin classes for each role we expect to fulfill, the Philosophical question is, how could we know that a new blank instance is needed if we didn't have a particular "thing" in mind in the first place? I.E. doesn't a thing still have to start as a particular "kind" of thing in order to know when it is time to create a new one? 

In still other words, is there an actual case of a "thing" that consists only of roles? Are we sure that one of those roles isn't a thing itself?  Does the technology give us the capability to do something that makes no ontological sense?

[1] "Looking At Philosophy: The Unbearable Heaviness of Philosophy Made Lighter",2005, Palmer

Cubist Programming?

In The Stuff of Thought by Steven Pinker, the book talks about human minds being able to hold multiple viewpoints simultaneously about the same event, and that resonates with my ideas for Existential Programming. It also reminded me of my thoughts that Cubism tried to illustrate the same idea. Cubist paintings simultaneously attach different viewpoints of something to the same single "object" (as Existential Programming would have different viewpoints/models of the same "data entity" kept together in the same object).



So, Existential Programming might well have been named Cubist Programming!

Subjective, Objective, Relative, Existential

In the imposing, but handy, Oxford Companion to Philosophy[1], there are entries about "objectivism and subjectivism"[2], and "relativism, epistemological"[3] that lead to the following observations:

• Objectivism says that some statements are objective, in that they are true independent of anyone's opinion. e.g. This ball is red. Alternatively, values assigned to properties can be dependent on other factors and be described by a function rather than a simple value. e.g. The color of Ayer's Rock is F(time-of-day, weather).
  
• Subjectivism says that (potentially all) statements are subjective, in that they are dependent on the opinion of the person making the statement. e.g. This cake is delicious.
• Relativism says that statements are always subjective even when the decider thinks he's made an objective evaluation. I.E. no evaluations are objective because man is always biased by his particular cultural, historical, religious, etc viewpoint, and no particular viewpoint is "the right one". e.g. This society is primitive.
  
• Existential Programming philosophy says that even if something is supposedly scalar & objective, and even if one does not subscribe to relativism (thus implying that there is no need to ascribe to values a particular data source), the reliability of any particular data source is never perfect, and thus one needs to model data as if relativism were true. I.E. keep track of "says who" for each "fact" and therefore be prepared to simultaneously handle/store multiple values for everything, tagging them with "says who", "said when", etc. So, in effect, there are no scalar values, only functions with at least a data source as a parameter.
  

[1] Oxford Companion to Philosophy, 2nd Ed, 2005
[2] ibid, pg 667
[3] ibid, pg 800

"Strong" typing not so strong?

I've been in debates about the wisdom of defining web services with "strongly" typed messages (with specific fields of "specific" types) versus more general messages with, say, fields containing XML content. I have argued that so-called strong types like integer and string are no more "strong" than a segment of XML. This is because the string (and to a lesser extent integer, float, etc) data types are so broad that they can't really be called "strong". Strings are almost always further interpreted by the software and people on both ends of a message.

This notion is embodied by the testing technique known as Equivalence Partitioning. [A good summary is in the article "Make Child's Play of Equivalence Class Partitioning".] It says that there is more detailed structure to data than string and integer and to only test at that level is to miss many crucial test cases. It defines subranges and such to guide what to test, in effect, defining more granular data types. Languages like Pascal and Ada had more refined data types like subranges but those ideas were lost when C-like languages (including C++ & Java) came into vogue.

Existential Programming would change the way data types are defined to get away from simply defining a structure that is an aggregation of "primitive data types". It would let data types define a function that computes whether (or how closely) a putative value meets the requirements for that data type. While one could put that logic in a "setter" method of a class, that doesn't work with direct assignments (via assignment operators) of values (at least in Java-like languages).

To see where even subrange definitions like Pascal/Ada allowed (e.g. 3..27) are not sufficient, look at the logic required to validate the month/day/year values of a date as detailed in the ECP article. Only an algorithm can encode what is required for legal values, not simple declarations of string and integer properties.

So, "strong" typing is a relative term.

atonal versus pantonal

While reading the Intellectual Devotional[1], I came across its page about the composer Arnold Schoenberg that described how his new musical composition technique (12-tone serialism) was described as "atonal" but he preferred the term "pantonal". This resonated with my desire that Existential Programming be recognized as multi-type programming rather than "type-less".

The analogy here is between the key signature of a piece of music, and an ontology of classes used in a program.

A key signature (e.g. C-major, d-minor) defines which notes are to be used, and the special relationships between different notes. To be "tonal" is to follow the rules of a particular key signature. To be "atonal" is to NOT follow the rules of any key signature. To be "pantonal" is to simultaneously follow the rules of multiple key signatures.

An ontology defines which types/classes are to be used, and the special relationships between different classes. To be "strongly-typed" is to follow the rules of a particular ontology. To be "type-less" is to NOT follow the rules of any ontology. To be "multi-typed" (i.e. existential programming) is to simultaneously follow the rules of multiple ontologies.

[1] "The Intellectual Devotional",2006, Kidder, Oppenheim
http://www.theintellectualdevotional.com/index.shtml

What is redundant?

In the handy Philosopher's Toolkit book[1], there is a section[2] explaining the difference between "analytic" statements and "synthetic" statements, and in another section[3], "a priori" versus "a posteriori". They are both similar in that they are trying to distinguish between what is known about X just from its definition versus things that would have to be thought through or experiments done to discover them. E.G. "all triangles have 3 sides" and "Joe, the bachelor, is unmarried" are obvious just from the definition of triangle and bachelor. Other statements like "water boils at 212 degrees Fahrenheit" and "Joe, the bachelor, has red hair" are not "entailed by" or "contained within" the definitions of water and bachelor.

There are arguments by philosophers, however, about what IS entailed by a concept or contained within a definition. Some would argue that the boiling point of water *is* contained within the concept of water whether a particular person happens to know that or not. Similarly the statement "all triangles have 180 degrees as the sum of their internal angles" is true independently of whether we know about it, (but a lot of people *wouldn't* know that).

So, in general, there will not be agreement from one ontology/model to another about which statements (i.e. data/attributes/relationships) are redundant. Should the "age" of an applicant for a job be stored because it was a field in the application form? Or, should it always be calculated from the birth date and the date of the application? Should a "short cut" relationship between 2 distantly related entities be explicitly supported by a model, or should it always be "calculated" by traversing all the intermediate links through the "six degrees of separation"?

Even though E/R models will normalize data to an objective standard, different modelers will break normalization for "performance reasons" on a subjective (and thus inconsistent) basis. Existential Programming counts this lack of agreement on "what is redundant" as yet another reason to embrace/support multiple ontologies simultaneously.

[1] The Philosopher's Toolkit, Julian Baggini and Peter S. Fosl, Blackwell Publishers, 2003, ISBN: 0631228748
[2] ibid, section 4.3
[3] ibid, section 4.1

Relativism, Absolutism, and Existential Programming

In the handy Philosopher's Toolkit book[1], there is a section[2] explaining the difference between relative statements and absolute statements (and similarly relativism and absolutism). As a prototypical example, it explains how before Einstein, the "time" an event occurred was considered an absolute statement. In other words, the whole universe would know what it meant because time was the same everywhere (just different time zones). However, Einstein revealed that time is relative to the location and speed of the observer and can't be the same everywhere. Plus, since there is no place and speed that could/should be considered the "official" one, all "times" are equally valid.

Because there are many aspects of reality and opinion that are considered relative by some number of people, Existential Programming counts this as yet another reason to embrace/support multiple ontologies simultaneously. Absolute vs Relative points of view are yet another aspect of modeling the world that traditional object-oriented and relational database modeling make assumptions about.

[1] The Philosopher's Toolkit, Julian Baggini and Peter S. Fosl, Blackwell Publishers, 2003, ISBN: 0631228748
[2] ibid, section 4.2

Introduction to Existential Programming Blog

This first entry for "Existential Programming" is meant to act as an introduction to the topic and an explanation for the backdated entries to be added over time. Around May, 2006 I had a series of brain farts (ahem, epiphanies) about computer software engineering that led to a theory I decided should be called "Existential Programming". Because I have now collected about a year and half of unedited notebook entries, and I now have enough of an idea of what I mean by Existential Programming to write it up, but because I don't yet have the time to polish a Manifesto into a magazine article, much less an academic paper, I have decided to start this blog and back fill it with my notebook contents, as well as, putting future entries here. The goal is to plant my flag on the topic and its ideas now, even if I can't write "Existential Programming, the Book" yet. [BTW, see my std blog disclaimers.]

A meta-idea above Existential Programming itself, is the more general notion that there should be much more explicit cross fertilization between ideas from Philosophy (with a capital "P") and ideas from software engineering (as practiced in industry). I call this "Philosophical Programming". Early on during my epiphanies, I had the intuition that Philosophy probably had something to say about my topic (even though I'd never taken a philosophy class). So, at age 50, I started reading Philosophy 101 books. It quickly became obvious that Philosophy has SO MUCH to say about data/class modeling topics that it is criminal how little explicit reference to it there is in the software practice literature. I distinguish between industry practice (and their books, blogs, magazines oriented towards tools and "best practices") versus academia. After I learned enough terminology to search for papers covering ideas similar to mine, I found that there is a whole subculture writing academic conference papers that don't really bleed over into industry conferences for things like Java or AJAX or SOA. So, my general "project" these days is to try to come up with practical application techniques based on otherwise esoteric topics.

What is "Existential Programming" and what are the central ideas associated with it? In a nutshell, it means to embrace the notion that "existence precedes essence". I.E. develop data models, object models, programming frameworks, etc. without imposing a single E/R model, OO class hierarchy, ontology, etc. By using techniques where "objects" and "entities" exist independently of a single "strong type", they can integrate multiple "strongly typed" data models by letting objects simultaneously reflect all those models. This differs from weakly typed programming, or completely type-less programming, as can be found in scripting languages like JavaScript. Ironically, it takes a "type-less" foundation to really seriously do strong types in a "multi-cultural" world. [And actually, JavaScript is not a bad platform to implement these ideas precisely because of its class-less orientation.]

The ZEN thought here is that until one can create a type-less object, one can not create an object which can be all types simultaneously.

The ideas that flow from this general notion (or more correctly, caused me to refactor the general notion out of these specific ideas), fall into general categories like:

• mixins
• data integration using semantic mapping
• code integration of uncooperative APIs and Frameworks
  
• promoting "roles" over "is-a subclassing"
• open classes and external methods
• ontology mediation
• object evolution and class/API versioning
  

Quantum Math for Fuzzy Ontologies

In my earlier post "Existential Programming as Quantum States", I mused that objects that were simultaneously carrying properties from multiple ontologies (i.e. multiple class hierarchies or data models), were like Quantum States in Quantum Physics.  This led me later to wonder what math had been developed to work with quantum states...i.e. is there some sort of quantum algebra that might be applicable to Existential Programming? It is needed because, in Existential Programming, a property of an object might carry multiple conflicting values simultaneously, each with varying degrees of certainty or confidence or error margins.

I found Wikipedia page on Quantum-indeterminacy which looks applicable.

Quantum indeterminacy can be quantitatively characterized by a probability distribution on the set of outcomes of measurements of an observable. The distribution is uniquely determined by the system state, and moreover quantum mechanics provides a recipe for calculating this probability distribution.

Indeterminacy in measurement was not an innovation of quantum mechanics, since it had been established early on by experimentalists that errors in measurement may lead to indeterminate outcomes. However, by the later half of the eighteenth century, measurement errors were well understood and it was known that they could either be reduced by better equipment or accounted for by statistical error models. In quantum mechanics, however, indeterminacy is of a much more fundamental nature, having nothing to do with errors or disturbance.

AHA! It dawns on me that going beyond the mere fuzzy logic idea of values having a probability or certainty factor, Existential Programming could have a fuzziness value for the property as a whole...as in "it is not certain that this property even applies to this object"...and even further it could mean "it is not certain that this property even applies to the entire Class".  A FUZZY ONTOLOGY: method of associating attributes/relationships with entities where each entity is not conclusively known. The value of a property may be certain (i.e. not vague or probabilistic), but whether that property belongs to this object is fuzzy.

Why would you want that ability?  How about data mining web pages where several people's names and a single birth-date (or phone number, address, etc) are found.  Even though it isn't known which person's name is associated with the birthday, one could associate the birth-date with each person with some fractional probability.  With enough out of focus wisps of data like this, from many web pages, the confidence factor of the right birthdate with the right person would rise to the top of the list of all possible dates (analogous to the way that very long range telescopes must accumulate lots of individual, seemingly random, photons to build up a picture of the stars/galaxies being imaged).  The fractional probability assigned could be calculated with heuristics like "lexical-distance-between-age-and-name is proportional to the probability assigned". This could make the "value" of a scalar property (like birth-date), in reality, the summarization of a complete histogram of values-by-source-web-pages.

POSTSCRIPT - May 21st, 2010

Came up with another AHA this AM that I later found in a French university's academic journal. I had the bright idea of "fuzzy frames" and sure enough later found "A theory of Fuzzy Frames" here... http://www.listic.univ-savoie.org/modules.php?name=Busefal&func=AfficherVolume&no_volume=31 I am not sure it is exactly the same since I was thinking of applying neural net type "learning" (of the sort used to recognize handwriting) on semantic network relations. The inspiration was the problem of how to handle all the variations on a "restaurant scenario" frame (see original Schank book).

Birth of a Blog

On this date I had the blinding realization that after a year and a half of thinking and note scribbling about this thing I was calling Existential Programming, I should grab the domain name and start a blog to plant my flag on the name and topic.  I had the thought while recording notes on the original ideas that led to Existential Programming...

Recalling the inspiration for Existential Programming, the concept

While working on a Javascript project in early 2006, I became aware of the differences between Java class-based objects and Javascript's prototype-based objects. I wanted to work with Java-like classes and researched existing attempts to implement them and what it would take to "do it right".  In the course of comparing different attempts, I came across different definitions of "class".

Once I realized the ability to dynamically add and delete attributes of an object in Javascript, I realized that one could nicely map them onto semantic-network relations/tuples. I already knew about EAV database schemas.  I had the epiphany that O/O and E/R and S/N modeling could all be made isomorphic once one had class-less objects as Javascript had.

Once I realized that classes were isomorphic to semantic networks, and having already known that computer ontologies were anything but universally agreed upon, I had the epiphany that OO class structures were too restrictive because they assume a single ontology.  On the other hand, I did not want to give up the benefits of strong typing.  So I had the idea that objects should be able to simultaneously house the attributes of multiple ontologies, and with class-less objects I could see how to implement the whole system.

Together, these trains of thought somehow gave rise to the intuition "I'll bet people have already thought about this...like maybe in Philosophy?". I quickly discovered it had everything to do with this topic. And once I found out what Existentialism was, it became clear that class-less objects have the same deep idea.

So, I coined the term "Existential Programming" to refer to the whole "project" of exploiting type-less objects to implement multiple strong types simultaneously.

Killer App of Existential Programming?

Ok, with all this theorizing about "existential programming", what the heck is it good for?
I.E. What is the killer app of existential programming?

The answer could be "integration of uncooperating systems"...

• Data Integration
• Data Model (i.e. schema) Integration
• Application Integration
• Frameworks API Integration

By developing an information (code/data) environment where different paradigms can coexist without even being aware of each other, uncooperating systems can be mediated between that otherwise could not.

Different orders of Polymorphism

When most computer science texts refer to polymorphism (in the context of object oriented programming) they are referring to either refining the implementation of a method via subclasses overriding that method, OR, by defining more than one behavior (method) with the same name. The former case (hopefully) preserves the semantics of the method name, the latter overloads multiple semantics on the same name. In either case, it is only the method that is multifaceted, not the entire object much less the class hierarchy.

With Existential Programming, a different order of polymorphism (i.e. "a single entity can take on multiple forms") is at work. Here a single entity in its entirety can take on multiple forms. Heck, it can take on multiple ontologies (aka class hierarchies). This means either supporting multiple (albeit, fundamentally similar) views/conceptions of an entity, OR, trying to knit together very different models where the object instance is in some sort of oscillating Schrodinger's Cat-like state (except that we can look at it and not affect its state :-).

Identifying Ontologies with URIs

As noted before in my original ephiphanies #10 & #15 and Level III Existential Programming, there should be a whole collection of meta-data around each "fact" documenting the source of that data, the time that data was acquired, etc, etc. This meta-data in effect constitutes an ontology definition; one per each different source/timestamp/etc. To be sure, these various ontologies are largely similar to each other and could benefit from an inheritance tree (ala OO class hierarchies).

In Java, such collections of definitions can be grouped into Packages. In XML, they can be grouped into Namespaces. So, a pragmatic way to factor out this metadata (such that it is not copied into every "fact"), is to give the ontology a name and tag each fact with that name (in the same way as each Java value is "tagged" with a data type that includes the Package name/path). And since, XML has already defined URIs as the format for namespace identifiers, and it is easy to map Package names with URIs, Existential Programming systems/languages could use URIs to identify the ontology associated with some set of facts. Since Existential Programming systems seek to seamlessly convert between an O/O and an E/R and an S/N representation, having OO packages easily mappable to data exchange mechanisms like XML is a good thing.

POSTSCRIPT - Nov 23rd, 2007
It is hard to tell which of my epiphanies are new and which are things I read long ago but later remembered as if they were a new idea...I'm sure I read this URI stuff in the Semantic Web articles (see Principle #1), but only "remembered" it when stumbling back across it today. At any rate, it was only recently that Tim Berners-Lee wrote this post about Linked Data using URIs.

Imaginary Numbers paradigm for Existential Programming

It occurs to me that one of the things that Existential Programming hopes to enable is the ability to continue working with data that is vague, fuzzy, semi-inconsistent instead of screeching to a halt as would be the case with a strongly-typed implementation of a single ontology.

An analog to this is the invention (discovery?) of Imaginary Numbers in mathematics. The imaginary number "i" is defined to be the square root of -1. Now the mildly mathematical reader will note that you can't have a square root of a negative number because any time you square a number it is always positive. So, when early mathematicians came to a point in their formulas where a square root of a negative number was required, they were stuck. By creating a way to talk about and manipulate numbers that "can't exist" (i.e. imaginary numbers), formulas could be worked through such that "real" answers could eventually emerge.

By developing techniques to work with data that is not consistent with a single ontology (i.e. existential programming), programs can get past the "thats not legal data" stage and work its way to answers that ultimately do result in "legal data".

Post Facto Polymorphism

Post Facto Polymorphism ®☺ is the Existential Programming technique of mapping an abstraction (defined after the fact of creating actual object instances or relational database entities or semantic network relations) to multiple preexisting ontologies (i.e. class/type definitions).

For example, suppose that there were several data sources that held data (specifically names) about "people", and these data sources were culturally specific. A typical European ontology/DB-schema might define 3 fields: firstName, middleName, lastName. A Native American oriented database might define a single Name field. An Asian database might have a familyName and a childName field. Yet another ethnic database encoded names into the European schema but understood that firstName was the "family name" for its data rather than lastName. If we wish to consolidate these data sources and define (after the fact) a new abstraction to work with all of them, we can use the external abstraction technique to adapt each of these apples and oranges to all be "fruit".

An AbstractName interface could be defined, and adapters defined for each "concrete class" that implement the mapping between that class' name-related properties and the properties of AbstractName. By having objects be "existential", thus allowing mixin adapter code to be dynamically added, the objects can all be accessed via the getFamilyName() and getTheNamePeopleCallMe() methods defined by AbstractName.

Of course, all this support for "cleaning up" data via external abstraction should not lessen the pressure to clean up the source data as much as possible (by which I mean cleaning up the schema and entity definitions more than the data itself). Otherwise, multiple "bad" data sources, each having their own classes/interfaces/source-of-record IDs/"package IDs", would need to be specified when referencing data in order to disambiguate which data source is desired. By cleaning up the schemas (to make the semantics more well-defined), fewer explicit "package ID" references are required, and one's code is much simpler/cleaner.

External Abstractions, Existential Classes, Object Views

Traditionally, object oriented modeling proceeds "top down" in that classes/interfaces are defined first and then instances (i.e. "objects") are created. Essence Precedes Existence. The objects consist of the class-defined attribute set, the whole class-defined attribute set, and nothing but the class-defined attribute set!

In Existential Programming, the developer can define "bottom up" classes/interfaces where, after the fact, attributes can be chosen from existing ones, or new "computed" attributes can be added. Existence Precedes Essence. This is very similar to the database concept of "view" where some subset of columns can be dealt with as if they were their own table/entity. These views can also add "computed" or "joined" columns thus supporting the philosophy that there is a fine (or non-existent) line between "behavior" and "data". They are all just properties, and it is inside the black box that the details exist of what was required to get or set that property (using Java-speak).

A difference between this object view idea and normal interfaces is that the interface declaring a method has to be defined before the class that implements it is defined, which in turn is before an object (based on that class definition) is created. With a view, an object could be "cast" to some defined-after-object-creation interface, as long as that object had the methods/properties that the view expected. Otherwise, potentially a cast-exception could be thrown (or, it could just let you work with any methods that *did* match). Of course, with Existential Programming, all "interfaces" and "classes" are the same as "views". There is no single "real" version of an object/entity with other versions just "views". This is different from database views where down deep there IS a "real" table (or several if the view was really a "join"). With Existential Programming's strategy of using EAV structure for persistence, all entity definitions / classes / interfaces are "views".

This sort of thing is done with dynamic languages like JavaScript and is called "duck typing". This name reflects 2 puns simultaneously:

1. "quacks-like-a-duck" typing (vs strong or weak typing)
2. duct taping (which is what all weakly typed programming is in the opinion of many)
   

In the same way database views can use logic to calculate attributes and join tables, existential classes/ontologies should be able to map/calculate each attribute via references to the attributes in other classes/ontologies. These ideas resonate with the "rules" in logic-programming languages like Prolog.

External Abstraction ®☺

A related idea I've had is that of the "external abstraction" where, instead of merely views, whole hierarchies of super-classes, subclasses, and interfaces are defined after the fact. ["Internal" abstractions would be those normal OO abstractions where the super-classes and interfaces supported by an object were those that were defined when the object instance was created (i.e. its essence).]

The point of "external" abstractions is that someone "external" (i.e. other than the ontology creator and object instantiator) can decide (after an object has been created) that some aspect of the object is overly specific to one point of view and needs to support other points of view. For example, the "name" attribute of "person" classes is often broken into first name, middle name, last name which is very culturally biased. So, support needs to be added for other cultures where "last name" is not synonymous with "family name", and there is no "Christian name", and not everyone has three names. Is Dances with Wolves' middle name "with"?

Normally, if one were refactoring that class hierarchy to better handle names, one would convert the 3 string fields representing the name into a reference to a new Name interface and define classes that implement various permutations of name. The interface could have methods like getFamilyName() which determined the value based on the particular cultural variant name class instantiated. This is all nice when one can do this beforehand such that is it all compiled and ready for the code to use before the person object is instantiated. With External Abstraction, the developer can do this refactoring and apply it to an entity that has already been created and exists as an object or persisted to some data store. By adding in a newly created " mixin" interface/class to the preexisting object, the 3 name fields can be reinterpreted and mapped to other ontologies supporting other cultures.

POSTSCRIPT - March 11th, 2011
I see that Google researchers have published papers in 2010 using my ideas about Object Views (although I'm sure they weren't aware of my 2006/2007 blog posts). For once, I wrote about something BEFORE the published papers of others. :-D See http://research.google.com/pubs/pub36273.html

Existential Programming as Quantum States

In reading about Quantum States in Wikipedia...

"In quantum physics, a quantum state is a mathematical object that fully describes a Quantum system. One typically imagines some experimental apparatus and procedure which "prepares" this quantum state; the mathematical object then reflects the setup of the apparatus. Quantum states can be statistically mixed, corresponding to an experiment involving a random change of the parameters. States obtained in this way are called mixed states, as opposed to pure states, which cannot be described as a mixture of others. When performing a certain measurement on a quantum state, the result generally described by a probability distribution, and the form that this distribution takes is completely determined by the quantum state and the observable describing the measurement. However, unlike in classical mechanics, the result of a measurement on even a pure quantum state is only determined probabilistically. This reflects a core difference between classical and quantum physics.

Mathematically, a pure quantum state is typically represented by a vector in a Hilbert space. In physics, bra-ket notation is often used to denote such vectors. Linear combinations (superpositions) of vectors can describe interference phenomena. Mixed quantum states are described by density matrices."

...I was struck by the analogy with Existential Programming which proposes that objects hold multiple values for various properties (and in fact multiple sets of properties, hence, multiple ontologies) simultaneously.

Unlike Quantum States however, reading one set of values doesn't make the other sets vanish! ;-)

Ontology Merging Strategy

Summarizing the posts from yesterday, there is a general problem of "things" in one ontology/data model not mapping (in a definite way) to "things" in another model. How to support (or even automate) mapping from one model to another? I.E. how to facilitate "transformation" from one "basis" to another?

A strategy at the heart of an existential programming language could be to reduce entities to their most atomic level: semantic relations between an entity and a single attribute. Use "identity" algorithms to reconstitute these atoms into "things".

A new language that did this and integrated multiple sources of data (OO data, E/R relational data, semantic networks, web-search-results) could create a single seamless framework and data continuum.
[Ed. Note: as found 10/29/07, others have had similar ideas.]