[cap-talk] a relationship is not an object

[John Carlson]

A relationship is not a thing or an object.  It's more like a having.
I have a parent.  I have a cat. I have a girlfriend.  Any attempt
at making a relationship a thing will fail, because it will have
no identity.  Certainly you can  enter a relationship into a database,
but at that point, I believe it becomes a contract.  Something
written down about the relationship.  Most relationships are
non-contractual, or we throw the contract away.   You have
food to eat, but you don't keep the receipt from the grocery
store stating your ownership of the food.

Here's an example of a relationship that becomes a contract:
There is a relationship between a part and an assembly
such that the assembly has several parts that it is made up
of.   The contract is the drawing or model that you send to
the supplier that says to put this part in this assembly.  But
the relationship between the part and the assembly doesn't
really exist as a separate thing that you can grab ahold of.

Thus I am interested in relationship-oriented programming.
I believe that things in a relationship send important messages
to each other.  The relationship is almost defined by the
messages sent between the things.  When those messages
are formally codified, the relationship becomes a contract.

So, what if we don't have a formal contract, but I still want
to send you messages?  What if I can't understand your
messages until I see enough of them to retrieve context
and meaning?

So, one can generate Dynamic Proxies with Java.  This
essentially creates a contract on the fly.  But how does
the service understand the new contract?  Now, it is
done by composition.  What I would like to suggest is
that we do it by learning.   The service should learn what
to do by the context and content of the unknown message.

This means:

1.   The client may need to define new terms.
2.   The service needs a way to store new definitions.

What we'd like the client to do is identify when a new
term would be useful, and pick some identifier from
the available list, create the definition of the identifier,
and pass that to the service.  The client and service
will need a common extensible language to create
definitions from.   Thus each service will have a
"this is a new definition" as part of the service (aka eval).  We
will probably want to allow definitions to be versioned.
Thus the language we are writing clients and services
in becomes a temporal language, with versions or
dates associated with every definition.

Interestingly enough, we are doing this kind of thing
in NIF right now, for the target data analysis.  We are
keeping track of the version that each module of
the analysis was at when an analysis is run.
I'm not sure we have this working yet, but we are working on it.

I guess this is a simple as recording your SCM tags with
the analysis results.

John