Using object-properties as described in the clogp401 development program increases flexibility primarily because it separates the computation of clogp from the application of this computation. Instead of providing preformatted "lowest common denominator" per CLOGP3, clogp401 provides the same information as application independent table objects (i.e., a sequence of sequence of strings).

This oopish concept can be pushed much farther. One can imagine a clogp algorithm not providing table objects at all, but rather providing all the objects (and relationships) that would go into making such tables. Like clogp401, all output would appear via molecule properties, but none of the properties would be as "output oriented" as a table. The "contribution table" would instead appear as a list of contribution objects whose components would be "live" fragments, real numbers, etc.

Such an API would be defined primarily by a description of the annotations that the program (let's call it "clogp501") attaches to the molecule as properties. For example:

The above list is not comprehensive (e.g., similar properties would be provided to describe electronic corrections).

Although with this scheme clogp501 does not provide "table output", it is clear that an application has all the information needed to produce such tables. For instance, for the Y-C-Y proximity correction:

molecule object
  "cp5contribs" property (sequence of contributions)
     contribution object (value 1.443)
       "cp5desc" property ("Y-C-Y proximity correction")
       "cp5entity" property (sequence of fragments)
	  fragment object (*OP(=S)(O*)S*, resides in fragdb)
	    "cp4name" property ("thiadiaza-2-one")
	    "cp4proxtype" property ("Y1")
	  fragment object (*n1n*sc1=O, resides in fragdb)
	    "cp4name" property ("thiophosporothioate")
	    "cp4proxtype" property ("Y1")

Given such detailed annotation of the molecule, it would be possible to create interfaces which vary drastically from the ones we've been considering up until now. For instance, one might write a Java Bean which works graphically, e.g., displays "clickable" depiction and tables which allow details of the computation to be examined by clicking on various parts of the molecule. Such details could extend all the way down to display of the fragment database record ... or, in the case of an "algorithm manager" right into the database, as an graphical database editor.

Is it worth adding such complex features to clogp? At first blush, probably not. But the complexity of such an interface may be more apparent than real. Complex as they seem, all these object relationships have to be organized within the algorithm, so all we're doing here is "publishing" them. The strength of this approach is that it might form a universal model for representing calculations of any kind.